<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.
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. chas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
