[concurrency-interest] Propagation of signals tonon-interruptedthread

David Holmes davidcholmes at aapt.net.au
Sun Nov 13 16:50:22 EST 2011


Martin,

I still oppose this and see little point in it. Why guarantee something only
to then say that noone should be acting based on the guarantee? What do you
gain by this? The ability to change a while loop to an if-statement - and
what does that gain you, a saving of  one comparison and one branch in a
code block that suspends a thread ???

David
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Martin
Buchholz
  Sent: Saturday, 12 November 2011 4:50 AM
  To: David M. Lloyd; Dr Heinz M. Kabutz
  Cc: concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] Propagation of signals
tonon-interruptedthread


  My latest spec proposal for ReentrantLock, with stronger disclaimer:


  --- java/util/concurrent/locks/ReentrantLock.java 9 Jun 2011
07:48:44 -0000 1.96
  +++ java/util/concurrent/locks/ReentrantLock.java 11 Nov 2011
18:41:22 -0000
  @@ -467,6 +467,13 @@
        * but for <em>fair</em> locks favors those threads that have been
        * waiting the longest.
        *
  +     * <li>None of the condition {@linkplain Condition#await() waiting}
  +     * methods ever return due to a "<em>spurious wakeup</em>".
  +     * However, as explained in the {@link Condition} documentation,
  +     * application programs should almost never rely on this guarantee.
  +     * A {@code Condition} should generally be waited upon in a loop,
  +     * testing the state predicate that is being waited for.
  +     *
        * </ul>
        *
        * @return the Condition object

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111114/a800fb80/attachment.html>


More information about the Concurrency-interest mailing list