Thanks, Hans.<div><br></div><div>Between the acquire/release model and the data-race check, I should be able to keep this straight!</div><div><br></div><div>However, even though I was one of the ones pointing out problems in the volatile spec in 1997 (after Tom May brought it to my attention), and I really should be capable of using them correctly, I haven&#39;t used volatiles in more than 10 years for anything more than a termination flag.</div>
<div><br></div><div>Whenever I see a volatile today, the only thing I know for certain is: there be bugs.</div><div><br></div><div>So, as a favor to me and others like me, please refrain from using volatile if there&#39;s a clearer way to do it.</div>
<div><br></div><div>Joe<br><br><div class="gmail_quote">On Mon, Feb 7, 2011 at 11:50 AM, Boehm, Hans wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I personally still think that by far the cleanest way to think about whether a variable should be volatile is to ask:<br>

<br>
Does it participate in a data race?  Can one thread be reading or writing it while another thread is writing it?  To answer this question use a simple interleaved (&quot;sequentially consistent&quot;) model in which nothing can be reordered.  In VolatileExample below (continuing to assume a single writer) x does not participate in a data race, since x is accessed by the reader only after it sees v true, and thus the writer must be done.  v can clearly participate in a data race, as can factory and isNuclearFactory in the original example.<br>

<br>
This does assume that:<br>
<br>
1) You apply this rule consistently.  If you don&#39;t declare v in the example below volatile, then the sequentially consistent reasoning I used to argue that x doesn&#39;t participate in a data race doesn&#39;t hold, since I no longer have a data-race-free program.<br>

<br>
2) Library implementers do the same, or at least make sure that library APIs are defined such that clients can continue to use sequentially consistent reasoning.  Currently, I think that&#39;s a goal of nearly all standard library APIs, at least in all cases in which reasonable client code can tell.  I suspect there are remaining bugs in some of the details.  But none of these issues arise in these examples.<br>

<br>
3) The program is otherwise correct under sequentially consistent reasoning.<br>
<font color="#888888"><br>
Hans<br>
</font><div class="im"><br></div></blockquote></div></div>