[concurrency-interest] Why can't wait-set Threads be privileged?

David Holmes davidcholmes at aapt.net.au
Sun Jun 30 18:30:53 EDT 2013

If you over-specify these things then you get locked into specific
implementations and if you are not careful you may not even be able to
implement them all on all platforms (ref the original Java Threads

The main reason to leave this loosely specified is performance. Any policy
that requires a specific hand-off of a monitor to another thread forces
context switches that may not be necessary. Think of a simple bounded-buffer
producers consumer situation where the consumer has blocked in wait()
because the buffer is empty and a producer is starting to fill it in  a

  while (true) {
    Item x = new Item();

inside put() there is logic to notify any waiting take() operations; and
put() /take() are synchronized of course. If the notify acted by moving the
consumer thread to the head of the monitor queue, and forced the producer to
block on the monitor the next time it called put() then the producer and
consumer will operate in lock-step with a lot of context switches. Instead
the current implementation simply places the consumer thread in the monitor
entry queue, but allows the producer thread to "barge" past the queued
consumer. This potentially allows the producer to fill the buffer before it
has to block, at which point the consumer generally gets a chance to drain
the buffer.

The devil is in the details of course, but the looser the spec the more
flexibility in the implementation.

Also note that the underlying system primitives (pthread condition
variables, UI-thread condition variables, win32 events) are equally loosely

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of
> thurstonn
> Sent: Sunday, 30 June 2013 12:28 PM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] Why can't wait-set Threads be
> privileged?
> So, in java the behavior of Object.wait and Object.notify():
> Thread 1:
> obj.wait() // Thread 1 is put in the wait-set
> Thread 2:
> obj.notify() // Select a Thread from the wait-set and move it to the
> *entry-set*
> What I've always wondered is why there isn't some sort of 'overloaded'
> Object.notify(...) that would essentially do:
> whichever thread is selected from the notify() call, put it at
> the 'head' of
> the wait-set so that it will enter the monitor next. (Note: what I'm
> suggesting is not the same thing as the 'fairness' parameter to
> ReentrantLock, e.g.)
> Obviously wait() and notify() are native methods, so what I'm
> wondering is:
> is this a limitation in modern OS's? CPUs?
> I don't know enough about the actual implementation to know what
> the issues
> are, but this would definitely be a useful feature (think multi-producer,
> single-consumer, etc).
> Of course there are other patterns that you can take to achieve similar
> results, but it would appear to be a lot simpler if you could just specify
> that is the behavior you want in an Object.notify(boolean:
> privilegewaiters)
> or some equivalent.
> Any insights?
> --
> View this message in context:
> http://jsr166-concurrency.10961.n7.nabble.com/Why-can-t-wait-set-T
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3345 / Virus Database: 3204/6448 - Release Date: 06/28/13

More information about the Concurrency-interest mailing list