[cpp-threads] memory model

Jason Merrill jason at redhat.com
Fri Apr 29 07:37:52 BST 2005


On Thu, 28 Apr 2005 15:31:06 -0700, "Boehm, Hans" <hans.boehm at hp.com> wrote:

> I think the main argument for redefining volatile is that it's
> currently very unclear what it means.  Even Itanium compilers
> don't agree.  Across architectures, it's hopeless.

I expected that changing volatile semantics would be controversial, so I
brought it up on the gcc mailing list:

  http://gcc.gnu.org/ml/gcc/2005-04/threads.html#00724

and indeed it has been.

> The most common definition seems to be that it prevents compiler
> reordering of volatile accesses, but lets the hardware do what it
> pleases.  I don't think this is useful to someone writing portable
> code and wants to know whether the operations become visible to
> an outside entity (hardware device, thread) in the order indicated,
> or not.

Actually, I think it is useful; it's a necessary feature that the user can
then build on with explicit memory barriers to get the ordering they need.
The memory barriers don't help if the compiler is reordering things.  If we
make volatile stronger, there might be no way for users to enforce a weaker
ordering that may be all they need.

Jason




More information about the cpp-threads mailing list