I think it would be helpful to hear directly from more of the folks who use the Unsafe stuff currently.<br><br>Is there anyone (besides Doug:) who can pipe up?<br><br><div class="gmail_quote">On Tue, Apr 20, 2010 at 9:19 AM, Gregg Wonderly<span dir="ltr"></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">Boehm, Hans wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

>From my perspective, it&#39;s important that<br>
</blockquote>
<br>
a) There is a usable subset of the language for which things are simple. I think that currently consists of programs that (1) contain no data races,<br>
and (2) avoid a certain set of library calls that include lazySet and a handful of others.  Java guarantees sequential consistency for this subset,<br>
and the visibility issues don&#39;t arise.<br>
</blockquote>
<br></div>
Data races seem to often appear as people try to make use of more &quot;cores&quot; by creating threading and associated localized processing which can result in publication of values between threads which then has to be mediated for visibility guarantees.  This is the specific problem that I seem to read about and see people having problems with over and over.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
b) There is an easy way to tell when you are leaving this subset. <br>
</blockquote>
&gt; This is currently getting a bit ugly.<br>
<br></div>
When there is more than one thread running, you have this problem.  For Java client programs, you have the EDT and the applications main thread that are separate.  If you then drive everything from EDT event dispatches, that can work for applications without networking or other background activity.  As soon as you add another thread, the possibilities of data races soar.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
For C++0x, the distinction (b) was made by requiring an explicit <br>
</blockquote>
&gt; memory_order_X argument when you want to leave this subset.  I&#39;m not sure<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
what the best way is to make this distinction in Java.  As Doug points out,<br>
the pre-existence of lazySet and weakCompareAndSet complicate matters. Possibly so does the desire to deal with array elements and the like; I&#39;m not sure.<br>
</blockquote>
<br></div>
Only publication of arrays creates the problem in a multi-threaded environment.  A single thread has no problems with an array.  Multiple threads are going to be a given in any Java application it seems to me, so I&#39;m not sure how any Java application can have sequential consistency without some degree of &quot;synchronized&quot; or &quot;volatile&quot; for any mutable values.<br>

<br>
It is all of the overhead and problems associated with the &quot;delay&quot; through such &quot;operations&quot; that we are talking about addressing I thought.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
It seems to me that either new classes or a C++0x-like approach would require<br>
</blockquote>
&gt; at least deprecation of lazySet and weakCompareAndSet.  That&#39;s likely to be<br>
&gt; to be a tough sell.<br>
<br></div>
Correctness of software is an important detail.  Being able to somehow understand and prove this is vital as we decide more and more on making software systems a part of things we depend on for continuous duty.<br><font color="#888888">
<br>
Gregg Wonderly</font><div><div></div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

From: Gregg Wonderly <br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
What I thinking about, is the fact that I see the read vs write accesses as a range of possibilities.  If you order them from weaker on the outside to stronger on the inside as something like<br>
<br>
        non-volatile -&gt; relaxed -&gt; volatile:read<br>
<br>
and<br>
<br>
        write:volatile &lt;- relaxed &lt;- non-volatile<br>
<br>
then you can imagine a &quot;window&quot; where particular guarantees can hold.  Outside of that window, things are weaker.  For any particular application, I am thinking that this window is never completely open.<br>
<br>
</blockquote>
I&#39;m not quite sure what you mean by &quot;window&quot; here.  One of the problems with the weaker ordering guarantees is that we don&#39;t seem to have a good handle on using weakly ordered operations (or data races on ordinary variables) in a way that is only locally visible.  Using weakly ordered operations anywhere seems to involve some danger of &quot;contaminating&quot; the whole program.  There do seem to be a few important idioms, like double-checked locking, that do localize the damage caused by weakly-ordered operations, but I don&#39;t know how to reason about that in general.<br>

<br>
If I had to pick three possible ordering guarantees for atomic variables, I would add some flavor of acquire-release ordering, and keep only one of &quot;non-volatile&quot; and &quot;relaxed&quot;.<br>
<br>
Hans<br></blockquote></div></div></blockquote></div>