I am not trying to change the spec for Condition or Object.<div><br><div>I am trying to change the spec for ReentrantLock, ReentrantReadWriteLock, AQS.ConditionObject, AQLS.ConditionObject to offer more guarantees than Condition does.</div>
<div><br></div><div>Martin<br><br><div class="gmail_quote">On Fri, Nov 11, 2011 at 11:47, Dr Heinz M. Kabutz <span dir="ltr"><<a href="mailto:heinz@javaspecialists.eu">heinz@javaspecialists.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><u></u>


  
  

<div bgcolor="#ffffff" text="#000000">
Remember to also change the Condition documentation:<br>
<br>
 * <p>When waiting upon a {@code Condition}, a
&quot;<em>spurious<br>
 * wakeup</em>&quot; is permitted to occur, in<br>
 * general, as a concession to the underlying platform semantics.<br>
 * This has little practical impact on most application programs as a<br>
 * {@code Condition} should always be waited upon in a loop, testing<br>
 * the state predicate that is being waited for.  An implementation is<br>
 * free to remove the possibility of spurious wakeups but it is<br>
 * recommended that applications programmers always assume that they can<br>
 * occur and so always wait in a loop.<br>
<br>
It is also mentioned in all the await() methods.<br>
<br>
This does worry me a bit though.  Just because it is not happening in
your implementation, is it then guaranteed to not happen in *any*
implementation?<br>
<pre cols="72"><div class="im">Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Development Professional
<a href="http://www.javaspecialists.eu" target="_blank">http://www.javaspecialists.eu</a>
Tel: <a href="tel:%2B30%2069%2072%20850%20460" value="+306972850460" target="_blank">+30 69 72 850 460</a></div>
Skype: kabutz 
</pre><div><div class="h5">
<br>
<br>
On 11/11/11 8:50 PM, Martin Buchholz wrote:
<blockquote type="cite">My latest spec proposal for ReentrantLock, with stronger
disclaimer:
  <div><br>
  </div>
  <div>
  <div>--- java/util/concurrent/locks/ReentrantLock.java<span style="white-space:pre-wrap"> </span>9 Jun 2011
07:48:44 -0000<span style="white-space:pre-wrap"> </span>1.96</div>
  <div>+++ java/util/concurrent/locks/ReentrantLock.java<span style="white-space:pre-wrap"> </span>11 Nov 2011
18:41:22 -0000</div>
  <div>@@ -467,6 +467,13 @@</div>
  <div>      * but for <em>fair</em> locks favors those
threads that have been</div>
  <div>      * waiting the longest.</div>
  <div>      *</div>
  <div>+     * <li>None of the condition {@linkplain
Condition#await() waiting}</div>
  <div>+     * methods ever return due to a
&quot;<em>spurious wakeup</em>&quot;.</div>
  <div>+     * However, as explained in the {@link Condition}
documentation,</div>
  <div>+     * application programs should almost never rely on this
guarantee.</div>
  <div>+     * A {@code Condition} should generally be waited upon in a
loop,</div>
  <div>+     * testing the state predicate that is being waited for.</div>
  <div>+     *</div>
  <div>      * </ul></div>
  <div>      *</div>
  <div>      * @return the Condition object</div>
  </div>
  <div><br>
  </div>
</blockquote>
</div></div></div>

</blockquote></div><br></div></div>