Hi Doug,<div><br></div><div>I need another clarification.</div><div><br></div><div>My understanding is that safe publication guarantees(ordering and visibility) of j.u.c.atomic classes are given because the internal variables are </div>
<div>declared volatile. Well! in the Hotspot additional barriers are applied in the unsafe native implementation.</div><div>This means(theoretically) in a NON Hotspot jvm the guarantees provided by the atomic classes wont break </div>
<div>even if the NON Hotspot JVM doesn&#39;t apply those additional barriers because the variable is declared volatile.</div><div>(I understand that x86/sparc CAS has the required ordering but what about Power platforms)</div>
<div><br></div><div>if this were so then doing a relaxed write on a volatile variable wouldn&#39;t make sense because volatile would guarantee</div><div>safe publication guarantees(ordering and visibility) as defined in spec.OR it has to be a special case processing.</div>
<div><br></div><div>Thanks in advance </div><div>Mohit </div><div><br><br><div class="gmail_quote">On Sat, Feb 26, 2011 at 10:30 PM,  <span dir="ltr">&lt;<a href="mailto:concurrency-interest-request@cs.oswego.edu">concurrency-interest-request@cs.oswego.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Send Concurrency-interest mailing list submissions to<br>
        <a href="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</a><br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
        <a href="mailto:concurrency-interest-request@cs.oswego.edu">concurrency-interest-request@cs.oswego.edu</a><br>
You can reach the person managing the list at<br>
        <a href="mailto:concurrency-interest-owner@cs.oswego.edu">concurrency-interest-owner@cs.oswego.edu</a><br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of Concurrency-interest digest...&quot;<br>
Today&#39;s Topics:<br>
   1. Re: Numa and ReentrantLock (Mohit Kumar)<br>
   2. Re: Numa and ReentrantLock (Doug Lea)<br>
Message: 1<br>
Date: Sat, 26 Feb 2011 21:09:03 +0530<br>
From: Mohit Kumar &lt;<a href="mailto:mohit.riverstone@gmail.com">mohit.riverstone@gmail.com</a>&gt;<br>
Subject: Re: [concurrency-interest] Numa and ReentrantLock<br>
To: <a href="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</a>, <a href="mailto:dl@cs.oswego.edu">dl@cs.oswego.edu</a><br>
        &lt;<a href="mailto:AANLkTimUauV1znGmfaoKieKZmNWth3WCS4RafSV5-cS3@mail.gmail.com">AANLkTimUauV1znGmfaoKieKZmNWth3WCS4RafSV5-cS3@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=&quot;iso-8859-1&quot;<br>
Hi Doug,<br>
In the ConcurrentHashMap the get method does not require<br>
&quot;readValueUnderLock&quot; because a racing remove does not make the value null.<br>
The value never becomes null on the from the removing thread. this means it<br>
is possible for get to return a value for key even if the removing thread<br>
(on the same key) has progressed till the point of cloning the preceding<br>
parts of the list.<br>
This is fine so long as it is the desired effect.<br>
But this means &quot;readValueUnderLock&quot; is not required for NEW memory model.<br>
However for the OLD memory model a put may see the value null due to<br>
reordering(Rare but possible).<br>
Is my understanding correct.<br>
Thanks in advance<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href="http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110226/399d0259/attachment-0001.html" target="_blank">http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110226/399d0259/attachment-0001.html</a>&gt;<br>

Message: 2<br>
Date: Sat, 26 Feb 2011 11:16:26 -0500<br>
From: Doug Lea &lt;<a href="mailto:dl@cs.oswego.edu">dl@cs.oswego.edu</a>&gt;<br>
Subject: Re: [concurrency-interest] Numa and ReentrantLock<br>
To: <a href="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</a><br>
Message-ID: &lt;<a href="mailto:4D69275A.8010009@cs.oswego.edu">4D69275A.8010009@cs.oswego.edu</a>&gt;<br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
On 02/26/11 10:39, Mohit Kumar wrote:<br>
&gt; Hi Doug,<br>
&gt; In the ConcurrentHashMap the get method does not require &quot;readValueUnderLock&quot;<br>
&gt; because a racing remove does not make the value null.<br>
&gt; Is my understanding correct.<br>
Not quite. You are right that it should never be called.<br>
However, the JLS/JMM can be read as not absolutely<br>
forbidding it from being called because of weaknesses<br>
in required ordering relationships among finals<br>
vs volatiles set in constructors (key is final, value is<br>
volatile), wrt the reads by threads using the<br>
entry objects. (In JMM-ese, ordering constraints for<br>
finals fall outside of the synchronizes-with relation.)<br>
That&#39;s the issue the doc comment (pasted below) refers to.<br>
No one has ever thought of any practical loophole that a<br>
processor/compiler might find to produce a null value read,<br>
and it may be provable that none exist (and perhaps someday<br>
a JLS/JMM revision will fill in gaps to clarify this),<br>
but Bill Pugh once suggested we put this in anyway just<br>
for the sake of being conservatively pedantically correct.<br>
In retrospect, I&#39;m not so sure this was a good idea, since<br>
it leads people to come up with exotic theories.<br>
      * Because the value field is volatile, not final, it is legal wrt<br>
      * the Java Memory Model for an unsynchronized reader to see null<br>
      * instead of initial value when read via a data race.  Although a<br>
      * reordering leading to this is not likely to ever actually<br>
      * occur, the Segment.readValueUnderLock method is used as a<br>
      * backup in case a null (pre-initialized) value is ever seen in<br>
      * an unsynchronized access method.<br>
     static final class HashEntry&lt;K,V&gt; {<br>
         final K key;<br>
         final int hash;<br>
         volatile V value;<br>
         final HashEntry&lt;K,V&gt; next;<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
End of Concurrency-interest Digest, Vol 73, Issue 15<br>