[concurrency-interest] Atomic assignment

Peter Reilly peter.kitt.reilly at gmail.com
Sat May 9 08:45:03 EDT 2009

On Sat, May 9, 2009 at 3:26 AM, David Holmes <davidcholmes at aapt.net.au> wrote:
> Mark Thornton writes:
>> David Holmes wrote:
>> > 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
>> >
>> >
>> By all accesses I presume you mean including things like ++, which is
>> reasonably well documented as not atomic.
> No - "access" is a simple load or store. ++ is an assignment operator that
> involves multiple operations: load, increment, store.
> Not sure why this has suddenly stirred up confusion. As Sam Berlin
> re-stated, all accesses to 32-bit types are atomic. The atomicity guarantee
> extends to double and long if they are declared 'volatile'. No assignment
> operators are defined to be atomic.
Just to be clear, writing to volatile longs/doubles/references are also atomic

from .above - 17.7 Non-atomic Treatment of double and long
Writes and reads of volatile long and double values are always atomic.
Writes to and reads of references are always atomic, regardless of
whether they are implemented as 32 or 64 bit values.

>> 4247780 doesn't appear to exist in the bug database.
> Sorry about that - that was actually a bug in the ExactVM which was the
> production VM on Solaris. Hotspot has its own bugs with regard to volatile,
> but as has been said the main bug was fixed years ago now.
> Cheers,
> David Holmes
> _______________________________________________
> 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