[concurrency-interest] Concurrency-interest Digest, Vol 73, Issue 15

Mohit Kumar mohit.riverstone at gmail.com
Thu Mar 3 02:57:23 EST 2011

Hi Doug,

I need another clarification.

My understanding is that safe publication guarantees(ordering and
visibility) of j.u.c.atomic classes are given because the internal variables
declared volatile. Well! in the Hotspot additional barriers are applied in
the unsafe native implementation.
This means(theoretically) in a NON Hotspot jvm the guarantees provided by
the atomic classes wont break
even if the NON Hotspot JVM doesn't apply those additional barriers because
the variable is declared volatile.
(I understand that x86/sparc CAS has the required ordering but what about
Power platforms)

if this were so then doing a relaxed write on a volatile variable wouldn't
make sense because volatile would guarantee
safe publication guarantees(ordering and visibility) as defined in spec.OR
it has to be a special case processing.

Thanks in advance

On Sat, Feb 26, 2011 at 10:30 PM, <
concurrency-interest-request at cs.oswego.edu> wrote:

> Send Concurrency-interest mailing list submissions to
>        concurrency-interest at cs.oswego.edu
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> or, via email, send a message with subject or body 'help' to
>        concurrency-interest-request at cs.oswego.edu
> You can reach the person managing the list at
>        concurrency-interest-owner at cs.oswego.edu
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Concurrency-interest digest..."
> Today's Topics:
>   1. Re: Numa and ReentrantLock (Mohit Kumar)
>   2. Re: Numa and ReentrantLock (Doug Lea)
> ----------------------------------------------------------------------
> Message: 1
> Date: Sat, 26 Feb 2011 21:09:03 +0530
> From: Mohit Kumar <mohit.riverstone at gmail.com>
> Subject: Re: [concurrency-interest] Numa and ReentrantLock
> To: concurrency-interest at cs.oswego.edu, dl at cs.oswego.edu
> Message-ID:
>        <AANLkTimUauV1znGmfaoKieKZmNWth3WCS4RafSV5-cS3 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> Hi Doug,
> In the ConcurrentHashMap the get method does not require
> "readValueUnderLock" because a racing remove does not make the value null.
> The value never becomes null on the from the removing thread. this means it
> is possible for get to return a value for key even if the removing thread
> (on the same key) has progressed till the point of cloning the preceding
> parts of the list.
> This is fine so long as it is the desired effect.
> But this means "readValueUnderLock" is not required for NEW memory model.
> However for the OLD memory model a put may see the value null due to
> reordering(Rare but possible).
> Is my understanding correct.
> Thanks in advance
> Mohit
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110226/399d0259/attachment-0001.html
> >
> ------------------------------
> Message: 2
> Date: Sat, 26 Feb 2011 11:16:26 -0500
> From: Doug Lea <dl at cs.oswego.edu>
> Subject: Re: [concurrency-interest] Numa and ReentrantLock
> To: concurrency-interest at cs.oswego.edu
> Message-ID: <4D69275A.8010009 at cs.oswego.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> On 02/26/11 10:39, Mohit Kumar wrote:
> > Hi Doug,
> >
> > In the ConcurrentHashMap the get method does not require
> "readValueUnderLock"
> > because a racing remove does not make the value null.
> >
> > Is my understanding correct.
> >
> Not quite. You are right that it should never be called.
> However, the JLS/JMM can be read as not absolutely
> forbidding it from being called because of weaknesses
> in required ordering relationships among finals
> vs volatiles set in constructors (key is final, value is
> volatile), wrt the reads by threads using the
> entry objects. (In JMM-ese, ordering constraints for
> finals fall outside of the synchronizes-with relation.)
> That's the issue the doc comment (pasted below) refers to.
> No one has ever thought of any practical loophole that a
> processor/compiler might find to produce a null value read,
> and it may be provable that none exist (and perhaps someday
> a JLS/JMM revision will fill in gaps to clarify this),
> but Bill Pugh once suggested we put this in anyway just
> for the sake of being conservatively pedantically correct.
> In retrospect, I'm not so sure this was a good idea, since
> it leads people to come up with exotic theories.
> ...
>      * Because the value field is volatile, not final, it is legal wrt
>      * the Java Memory Model for an unsynchronized reader to see null
>      * instead of initial value when read via a data race.  Although a
>      * reordering leading to this is not likely to ever actually
>      * occur, the Segment.readValueUnderLock method is used as a
>      * backup in case a null (pre-initialized) value is ever seen in
>      * an unsynchronized access method.
>      */
>     static final class HashEntry<K,V> {
>         final K key;
>         final int hash;
>         volatile V value;
>         final HashEntry<K,V> next;
> ------------------------------
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> End of Concurrency-interest Digest, Vol 73, Issue 15
> ****************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110303/860019b5/attachment.html>

More information about the Concurrency-interest mailing list