commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Thoughts about multi-threading
Date Fri, 21 Sep 2012 18:56:24 GMT
Am 20.09.2012 22:38, schrieb Honton, Charles:
> <snip>
>>>> This obviously makes the concurrency problem easier :)
>>>> Apart from this case, it would be good to agree on exactly what it
>>>> means for [configuration] to be threadsafe.  Is it basically the
>>>> semantics of ConcurrentHashmap?  Or are there sequencing / event
>>>> serialization constraints?  For example, suppose the sequence below
>>>> happens
>>>> Thread A start add property
>>>> Thread B start clear
>>>> Thread A notify property change
>>>> Thread B notify clear
>>>> Thread B clear map
>>>> Thread A update map
>>>> Is it OK for this sequence to happen?  Is it OK for A's add to trump
>>>> B's clear even though B's activation started later and B's
>>>> notification was later?
>>> This is a very good point, I did not think about this. It would be
>>> very confusing for an event listener to receive a clear event and
>>> then find out that the configuration is not empty.
>>> So I guess it is too naive to simply replace the plain map by a
>>> concurrent map to gain thread-safety. We will then probably have
>>> to use a read-write lock for map-based configurations, too. Well,
>>> this is not too bad. The only thing which worries me a bit is that
>>> we have to call event listeners while the lock is held. This is an
>>> anti-pattern described by Bloch: "Don't call an alien method with
>>> a lock held!". Does anybody has an idea how we could prevent this?
>> Interesting problem.  Unfortunately, I don't think you can enforce
>> the serializability invariant (no interleaving as above) without
>> some [configuration] thread holding a lock while notification
>> happens.  You could queue notify-update tasks so add/update
>> invocations don't block; but whatever thread actually executes the
>> tasks would have to lock takes from the queue while notifies
>> complete.  That might not be that bad, since you could continue to
>> services reads (of yet-to-be-updated data) and queue updates while
>> the foreign lock was held; but it still violates the maxim, with the
>> consequence that a hung listener could stop updates from happening.

For a similar problem I once used a single-threaded executor. The code 
holding the lock just scheduled tasks at the executor which were 
responsible for sending notifications to event listeners. The tasks were 
initialized with the events to propagate and a snapshot of the currently 
registered event listeners.

Not sure whether this is a suitable approach for the problem at hand. It 
is probably not a good idea to create a new executor service for each 
Configuration object. And having a single shared instance can become a 
bottle neck.

> Is serializability what's desired?  Or is it consistency?  I can imagine a
> situation where multiple properties must enforce some invariant
> relationship.  The producer would like to be able to hold off notifying
> the property consumers before the next property change fixes the invariant
> constraint violation.  Likewise the consumer might want a set which is
> invariant between applying the first property and the last property.

Honestly, I don't know. I hope that we can start with something simple 
and then build advanced functionality on top of it.


> chas
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message