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