[concurrency-interest] Atomic assignment

David Holmes davidcholmes at aapt.net.au
Tue Jun 23 08:27:36 EDT 2009


Denis,

- synchronization (ie use of locks/monitors) gives mutual exclusion and
visibility.
- volatile gives visibility and atomic load/store for long/double
- the language gives atomic load/store for all other types

So if you're using 64-bit types and don't need mutual exclusion then
volatile will suffice.

Cheers,
David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Denis
> Bazhenov
> Sent: Tuesday, 23 June 2009 10:07 PM
> To: concurrency-interest at cs.oswego.edu
> Cc: Brian Goetz
> Subject: Re: [concurrency-interest] Atomic assignment
>
>
>
> 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
>
> _______________________________________________
> 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