Comments on: Effective Concurrency: volatile vs. volatile

By: Herb Sutter

Herb Sutter — Mon, 10 Aug 2009 20:37:08 +0000

@Yang: That’s not quite true. In .NET today, ‘volatile’ operations are sequentially consistent (SC, fully ordered) except only that a volatile store followed by a volatile load can be reordered. This is true on both x86/x64 and Itanium. This doesn’t affect most uses of volatile, although Joe Duffy correctly explains in that article and in his blog that there are situations where it can change the expected meaning of code. I consider this a weakness, and am working with the CLR team to make .NET volatiles be SC in a future release post-VS2010 as part of my Prism memory model work. Note that the above does not apply to Java volatiles, which have been guaranteed to be SC since JSR-133 / Java 5.

By: Yang

Yang — Sun, 09 Aug 2009 23:46:58 +0000

Your article states that for .NET, `volatile` operations cannot be reordered (implies a memory barrier) . However, according to the following article (and various other resources I’ve encountered on the web):

http://msdn.microsoft.com/en-us/magazine/cc817398.aspx

operations are allowed be reordered. Any memory barrier must be explicitly created.

By: Pierre Phaneuf

Pierre Phaneuf — Mon, 20 Jul 2009 01:15:48 +0000

I wonder why there is so much “volatile” peppered all over the atomic functions on Windows and Mac OS X (the GCC built-ins do not, as I would expect)?

By: Herb Sutter

Herb Sutter — Mon, 02 Mar 2009 19:23:41 +0000

Norbert asked:

in your article you mention “volatile atomic” as a way to make a variable of being both, of unusual type (volatile) and to guarantee its atomicity.
What would be the difference to “atomic”?

A variable declared C++0x “volatile atomic” will have the union of the guarantees (and restrictions) of “C/C++ volatile” andstd:: “atomic”. It will be suitable for both inter-thread communication and communication with threads or hardware that don’t follow the memory model. It’s unusual to need that in practice, as you usually use one control variable to synchronize among your own threads, where atomic is the right tool, and another kind of variable to talk to hardware or otherwise unusual memory, where volatile is the right tool. Still, they’re orthogonal concepts and if you do want both C++0x will let you express it.

By: Norbert Riedlin

Norbert Riedlin — Mon, 09 Feb 2009 10:50:20 +0000

Hm, seem as if I have to type “<” when I need a “less than” character. So I’ll try again:
“What would be the difference to “atomic ”?”

By: Norbert Riedlin

Norbert Riedlin — Fri, 06 Feb 2009 11:18:35 +0000

Sorry, hit the submit button too early. The question should read:
“What would be the difference to “atomic”?”

By: Norbert Riedlin

Norbert Riedlin — Fri, 06 Feb 2009 08:23:38 +0000

Hi Herb,

in your article you mention “volatile atomic” as a way to make a variable of being both, of unusual type (volatile) and to guarantee its atomicity.
What would be the difference to “atomic”?

By: Marco Dalla Gasperina

Marco Dalla Gasperina — Wed, 21 Jan 2009 14:58:06 +0000

“volatile” doesn’t require hardware registers or address multiplexing to be necessary. Common APIs like shared memory between processes can fit the bill as well.

By: Kimo Crossman

Kimo Crossman — Sat, 17 Jan 2009 17:49:34 +0000

Herb

Will you be commenting on the multicores advantages stop at about 8 study from US Gov. Sandia and Oak Ridge labs:

http://www.theregister.co.uk/2009/01/15/sandia_boffins_multicore_dropoff/

By: Herb Sutter

Herb Sutter — Tue, 13 Jan 2009 17:41:14 +0000

Nick: Yes, the issues apply in principle to uniprocessor systems too. Think of it this way: Any level of the execution chain, from compiler to processor to cache (to future transactional memory in SW or HW to anything else) can transform reads and writes and must play nice with the memory model. On a uniproc system, you eliminate only processor and probably cache from that list, but the remaining parts (e.g., the compiler) can still perform unwanted transformations.

Roger: Yes, that’s another valid example. The list wasn’t meant to be exhaustive, just to give a few common examples to motivate why this is a legitimate issue. Another one I mentioned in the table but not in the text is setjmp-safety; there are more.

By: Roger Gammans

Roger Gammans — Tue, 13 Jan 2009 12:59:09 +0000

Re C++ style, volatile.

When I was doing a lot of hardware engineering once of the classic hardware semantics was reading from a register to trigger an event.
You don’t mention this in your classic examples list , is this because it is not safe to assume the compiler won’t add additional reads of a volatile register to the code?

By: Nick Terry

Nick Terry — Mon, 12 Jan 2009 18:53:21 +0000

The articles on Lock-free programming have been immensely useful even from the lock based concurrency perspective.

I have a question hoping you have some insight. Do these issues you’ve described with lock-free programming exist on uniprocessor systems?

In particular I am interested problems arising from processor or cache memory reordering. The assembly can always be inspected to verify that compiler hasn’t produced non-thread-safe code.