At 09:00 AM 8/08/2003 -0400, Doug Lea wrote.
>How many orders of magnitude of performance penalty do you consider
>"reasonable cost"? :-)
Ok, for the sake of argument, let's say that I'm willing to tolerate a few
hundred percent performance cost relating just to these primitives. After
all, real programs spend most of their time doing other things, and in any
case if I were trying to squeeze the last possible flop out of my system, I
wouldn't be writing in Java. More likely, I'm using Java because I want to
be able to develop working programs using software engineers of average
talent (which, sad to say, is not an impressive level).
>Much of the Java code that relies heavily on wait/notify/interrupt
>runs on multiprocessors. Yet the only constructive design for obeying
>original spec that anyone (Sylvia) has presented on this list requires
>a global lock, plus as least twice the number of context switches as
>otherwise necessary, which are just not acceptable.
After some thought, I believe that I can eliminate the global lock by means
of a careful choice of the structure used for the wait set. This would
eliminate the need to acquire a lock on the wait set, or its containing
object, when traversing it or removing a thread from it. It was this
requirement that caused the problem with acquiring the same two locks in
the opposite order, and which lead to my using a global lock.
As for the context switches, I'm not quite sure what you're referring to.
It's true that my design probably requires more switches between
application and kernel modes. Some architectures handle this better than
others, but should it be regarded as a particularly high cost? Causing an
increased number of switches between threads would be another matter, but
I'm not aware that my design does that.
>The issue here is essentially the same as has been controversial in
>concurrent programming for about 15 years now (at least ever since
>DEC-SRC Firefly project): On multiprocessors, there are no known
>techniques for uniquely agreeing on the "winners" of some of these
>wake-up races (in many cases, from the hardware on up), so each level
>of a system errs on the side of liveness, and unblocks threads if
>there is any question about it. The extra-notification trick proposed
>as response to to unknowably lost races between interrupt and notify
>falls in this tradition. (Sad but apparently true that it needs to act
>as a notifyAll.)
This seems to be in conflict with my proposed solution. Either my design is
irreparably incorrect, and no correct solution exists, or the race
conditions referred to are not ones that impact on the problem at hand.
Sylvia.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:50 EDT