These discussions always seem to get out of hand. People have
different preferences and expectations about how to handle all the
policy, performance, and runtime/OS issues that arise when blocking
and unblocking threads.
Part of the reason JSR166 exists is to allow people to create
synchronization objects that provide just about any policy. As David
mentioned, there are a large number of known alternatives (some of
which were discussed in Peter Buhr's survey paper), all of which
appear implementable using JSR166 primitives. So, if you want
waiter-preference, urgent-signal, implicit-signal, etc., semantics,
you can build and use a corresponding Condition class. This is not
usually easy, but is at least possible.
In fact, semantics of Object.wait only indirectly impact JSR166 since
we use our own Condition implementations throughout
java.util.concurrent. To meet the responsiveness requirements of the
j.u.c classes that internally use Conditions (queues, futures, thread
pools, etc), we rely on Condition.await to throw IE if the thread is
interrupted at any point before returning. Other users of Condition
are apparently content with this. I received only one reply to JSR166
interest list post about policy, by someone who said they could go
either way on it. I conclude that some of the other 287 subscribers
desire current approach, some don't care, some are too busy to reply,
and some are just hoping that the "experts" settle all this for
them. (A more important goal of JSR166 is to provide enough utilities
so that far fewer people will ever directly use monitor/condition
methods, but will instead use higher-level constructions based upon
them.)
It would be nicest in terms of learnability and interoperability if
Condition.await implementations matched the policy for Object.wait.
If they turn out not to, I suppose we could add a method, say,
"awaitPedantically()" to the main ReentrantLock.ConditionObject
implementation that exactly matches Object.wait semantics, just in
case anyone ever wants this.
I'm not sure what to conclude from all this wrt JSR133 Object.wait
spec. The current impass boils down to matters of preference --
choosing a policy that most often does what people want versus a
policy that people may find easier to understand. And no one has been
able to find a reason to eliminate either policy from
consideration. Until/unless someone does, there will be people unhappy
with whichever way the JSR133 spec goes.
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:54 EDT