[concurrency-interest] How bad can volatile long++ be?

Gregg Wonderly gregg at cytetech.com
Wed Dec 12 17:40:00 EST 2007

Osvaldo Pinali Doederlein wrote:
> Sorry, when I wrote that comment I was thinking too hard about 
> Consistency, not Atomicity. I meant that the alignment should prevent, 
> for example, that thread 1 writes 0x0000000000000000 and thread 2 
> concurrently writes 0xFFFFFFFFFFFFFFFF, and the result in memory is 
> something like 0x00000000FFFFFFFF due to bad luck in cache-RAM sync'ing; 
> but that's all (but correct me again if I am wrong even in this assumption).

Okay, my perspective on all of this is that these types of comments and 
assumptions are what have created really poor mappings between software and what 
hardware can and can not vs will and will not do.  The classes, concepts and 
constructs that are being generated as part of the concurrency research that 
Doug and others are doing, are finally creating a nice layer of separation 
between hardware and software which allows hardware and software realities to be 
completely separated.

The software is finally expressing exactly what its intent is, and the classes 
and JMM implementations can provide the low level details of implementation 
without the software having to worry about what those are.

There are obviously use cases which can not be distinctly programmed as 100% 
optimal use of hardware capabilities still today.  But, the things that 
multi-core, multi-path memory are meant to address are directly accessible by 
the concurrency software which is flowing out of this work, and I think it's 
time to stop talking about hardware, and only talk about exactly what we want 
the software to do, and then design classes (or JMM specs if really needed) 
which provide the manifestation of that need which can then be targeted to the 
hardware that is available at that time.

Gregg Wonderly

More information about the Concurrency-interest mailing list