[concurrency-interest] How bad can volatile long++ be?
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
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.
More information about the Concurrency-interest