views:

687

answers:

3

From what I've read from Herb Sutter and others you would think that volatile and concurrent programming were completely orthogonal concepts, at least as far as C/C++ are concerned.

However, in GCC c++0x extension all of std::atomic's member functions have the volatile qualifier. The same is true in Anthony Williams's implementation of std::atomic.

So what's deal, do my atomic<> variables need be volatile or not?

+18  A: 

So that volatile objects can also be atomic. See here:

The relevant quote is

The functions and operations are defined to work with volatile objects, so that variables that should be volatile can also be atomic. The volatile qualifier, however, is not required for atomicity.

And no, atomic objects don't have to be volatile.

stephan
Ah, nice find. Hope you don't mind I inserted the specific quote from that paper.
jalf
@jalf: perfect, thanks.
stephan
+4  A: 

As const, volatile is transitive. If you declare a method as volatile then you cannot call any non-volatile method on it or any of its member attributes. By having std::atomic methods volatile you allow calls from volatile member methods in classes that contain the std::atomic variables.

I am not having a good day... so confusing... maybe a little example helps:

struct element {
   void op1() volatile;
   void op2();
};
struct container {
   void foo() volatile {
      e.op1();  // correct
      //e.op2();  // compile time error
   }
   element e;
};
David Rodríguez - dribeas
+21  A: 

To summarize what others have correctly written:

C/C++ volatile is for hardware access and interrupts. C++0x atomic<> is for inter-thread communication (e.g., in lock-free code). Those two concepts/uses are orthogonal, but they have overlapping requirements and that is why people have often confused the two.

The reason that atomic<> has volatile-qualified functions is the same reason it has const-qualified functions, because it's possible in principle for an object be both atomic<> and also const and/or volatile.

Of course, as my article pointed out, a further source of confusion is that C/C++ volatile isn't the same as C#/Java volatile (the latter is basically equivalent to C++0x atomic<>).

Herb Sutter
I am going to abuse the fact that you are here to ask your opinion about an article by Alexandrescu on using the `volatile` flag to produce compile-time errors on thread-unsafe code (using `volatile` instances to lock the use of the interface and `const_cast` to remove the volatile when a mutex is acquire). Could it make sense adding a type qualifier 'threadsafe' or the like for this purpose in the language (I am just thinking out loud) The article is here: http://www.drdobbs.com/cpp/184403766;jsessionid=OEWBPI10M2IQLQE1GHPCKHWATMY32JVN
David Rodríguez - dribeas
I have added it as a question here: http://stackoverflow.com/questions/2491495
David Rodríguez - dribeas
In some of Andrei's articles, what he was really doing wasto hijack (er, I mean, "reuse") the volatile keyword as a handymostly-unused tag in the type system he could use as a hook tooverload and get other effects, which was a little confusing becauseit wasn't stated quite that way.
Herb Sutter