[concurrency-interest] Atomic assignment

Denis Bazhenov bazhenov at farpost.com
Tue Jun 23 08:06:54 EDT 2009


Is synchronization on 64-bit types required to force visibility  
guarantee?

As far as I understand, if new variable value is not depend on  
previous value (in other terms all I need is memory visibility and  
assignment atomicity) I can use volatile variables without  
synchronization. Is it correct, or I missed something?

Denis Bazhenov



On May 11, 2009, at 8:34 AM, Brian Goetz wrote:

> In general, the issue over word tearing for nonvolatile longs/ 
> doubles is kind of a red herring; word tearing would occur when the  
> variable is shared between threads, in which case, you should be  
> synchronizing anyway (otherwise you risk stale values.)  So there's  
> very little "special" about thread-safety for longs/doubles --  
> unless you are deliberately writing code with data races, in which  
> case there is just one more failure mode.
>
> Gregg Wonderly wrote:
>> Okay, it we actually just have the ++/-- not atomic issue, than I  
>> am okay with that because I don't suddenly have new, broken code.   
>> I looked around some more and ran the test code on that old issue  
>> on my dual core laptop and saw no failures.  But, I'm not sure  
>> after looking at that code whether it actually makes modifications  
>> in a way that would show a problem.
>> Gregg Wonderly
>> Sam Berlin wrote:
>>> My interpretation is that the scenario today is that a volatile  
>>> long/double is atomic.  A non-volatile long/double is not atomic.   
>>> And the RFE that was closed as will-not-fix was asking for all  
>>> access to long/double (even non-volatile) to be atomic.
>>>
>>> Sam
>>>
>>> On Fri, May 8, 2009 at 10:27 AM, Gregg Wonderly  
>>> <gregg at cytetech.com <mailto:gregg at cytetech.com>> wrote:
>>>
>>>    So will the compiler be changed to not allow volatile to exist on
>>>    double/long declarations since it does not work?  Or might  
>>> there be
>>>    a warning that volatile does not produce atomic results on all
>>>    statements that assign to or reference a double/long value?
>>>
>>>    Sigh...
>>>
>>>    Gregg Wonderly
>>>
>>>
>>>    David Holmes wrote:
>>>
>>>        Hi Mark,
>>>
>>>        That bug is (or became) a RFE for the spec to make all  
>>> accesses to
>>>        double/long atomic and that is not going to happen hence the
>>>        "will not fix".
>>>        There are a number of other bugs that pertain to atomic  
>>> access
>>>        to volatile
>>>        long/double eg: 4247780 which was fixed back in 1.2.2
>>>
>>>        Thanks
>>>        David Holmes
>>>
>>>            -----Original Message-----
>>>            From: concurrency-interest-bounces at cs.oswego.edu
>>>            <mailto:concurrency-interest-bounces at cs.oswego.edu>
>>>            [mailto:concurrency-interest-bounces at cs.oswego.edu
>>>            <mailto:concurrency-interest-bounces at cs.oswego.edu>]On
>>>            Behalf Of Mark
>>>            Thornton
>>>            Sent: Friday, 8 May 2009 7:29 AM
>>>            To: concurrency-interest at cs.oswego.edu
>>>            <mailto:concurrency-interest at cs.oswego.edu>
>>>            Subject: [concurrency-interest] Atomic assignment
>>>
>>>
>>>
>>>            I was sure that the problem of (non)atomic assignment to
>>>            volatile longs
>>>            and doubles had been fixed, but this bug report suggests
>>>            otherwise:
>>>
>>>            http://bugs.sun.com/bugdatabase/view_bug.do? 
>>> bug_id=4023233
>>>
>>>            Anyone know for sure?
>>>
>>>            Mark Thornton
>>>
>>>            _______________________________________________
>>>            Concurrency-interest mailing list
>>>            Concurrency-interest at cs.oswego.edu
>>>            <mailto:Concurrency-interest at cs.oswego.edu>
>>>            http://cs.oswego.edu/mailman/listinfo/concurrency- 
>>> interest
>>>
>>>
>>>
>>>        _______________________________________________
>>>        Concurrency-interest mailing list
>>>        Concurrency-interest at cs.oswego.edu
>>>        <mailto:Concurrency-interest at cs.oswego.edu>
>>>        http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>>
>>>    _______________________________________________
>>>    Concurrency-interest mailing list
>>>    Concurrency-interest at cs.oswego.edu
>>>    <mailto:Concurrency-interest at cs.oswego.edu>
>>>    http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list