[cpp-threads] memory model

[Doug Lea]

Jason Merrill wrote:
> 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.
> 


I guess the question here is who we are most afraid of offending:

  * People who would be unhappy that providing semantics for
    volatile might sometimes make existing usages more expensive

  * People who would be unhappy adding another qualifier
    to mean "accessible by multiple threads without a lock",
    (that would in most cases have exactly the semantics
    of volatile).

  * People who would be unhappy to have to declare every
    volatile-like variable using atomic templates (which
    avoids keywords but is programmer-hostile.)

Maybe we need a vote about this.
If the "let them eat razor blades!" solution wins out here,
we need to know about it soon to make further progress.

> 
> 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.
> 

It has always been the intent to offer more flexible barriers
within atomics library -- to make people who need more fine-grained
control pay for it in terms of awkward and error-prone syntax. We
probably made a logistic mistake in not fleshing this part out in
Lillehammer document, which makes it look like we ignored it, when
actually, we just haven't gotten around to spec'ing it out.

-Doug