WriteLocks, Conditions, and signal() (to readers)

Question

We are creating a simulation application where one thread periodically updates each object, and other threads read information from it. We had liveness problems when using a simple synchronization scheme, so we had hoped to use ReentrantReadWriteLocks (RRWL) instead.
If a reader got the read lock on an object, it could check if it was up-to-date, and, if not, await() on a Condition associated with the write lock. This would free up the object to allow the writer to acquire the write lock, update it, and, when finished, signalAll() on the Condition to allow the readers to continue.
However, the Condition and RRWL classes are currently not designed to allow this. Only objects that have the WriteLock may await on the associated Condition. It makes sense that only objects that have the write lock could signalAll(), since threads should not signal without updating the state first. However, I don't understand why having a write lock is required to await() on the associated Condition. The tryRelease() method of RRWL throws an exception if the calling thread is not the owner of the associated lock.
Since other implementations of RRWL (Colt, Apache commons) don't seem to support what we want in a RRWL either, we are left to implement what we want ourselves. Is there a good workaround to allow all of the readers to be signaled when the writer is finished? Otherwise, will subclassing RRWL and overriding the tryRelease() method cause other big problems?

Answer 1

We had thought about acquiring the write lock before
calling await(), but then only one thread would be
signaled.I don't understand why you think this would be the case. As many threads as were waiting when the signalAll was done would be signalled.
In the simulation, each object has its own thread.
We use a barrier to synchronize update steps, but
there is a data dependency between objects. The
dependencies between objects is variable (which one
depends on another). When an object is updating it
tries to get a write lock, but may be blocked
because a dependent object (or > 1) has a read lock.
We want the dependent object(s) to await() the
update from the writing thread (thus each giving up
their read lock), which means they should all be
signaled. I think I get the picture. At the barrier all objects that need to be updated are marked as out-of-date. The thread for a given object then attempts to update that object by getting the write-lock and then working out the next state by querying the dependent objects. However a dependent object may be in need of an update in which case you want to wait until that update is done.
It still seems to me that grabbing the write-lock of the dependent object and then waiting for its update to complete is the simplest immediate solution.
Our current thought is to try to subclass RRWL and
override tryRelease() to support the case where owner
== null. I don't think it is that simple. The ConditionObject code in AQS uses the fact that the associated exclusive lock is held to protect concurrent access to its own data structures. You simply can't call await() if only holding shared access.