[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