This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Heads-up: volatile and C++

On Thu, 14 Apr 2005 16:04:33 -0400, Diego Novillo <> wrote:

> On Thu, Apr 14, 2005 at 05:40:04PM +0200, Jason Merrill wrote:
>> But the memory model for the language must provide semantics that make it
>> possible for threaded programs to be written.  Currently, if you want to
>> write a portable pthreads program you need to use a mutex around all uses
>> of shared memory, because they are the only way to guarantee sequential
>> memory ordering.  The volatile proposal provides a lighter-weight way to
>> write portable code with explicit memory ordering.  You need this for
>> lockless algorithms to work.

> Not necessarily.  Sequential memory ordering is not always
> desirable.  There exist concurrent algorithms out there that rely
> on extremely weak memory ordering semantics for performance.

I shouldn't have used the term "sequential memory ordering."  Nobody is
suggesting that C++ should enforce sequential consistency between threads.
But even in the weakest memory models...*especially* in the weakest memory
models, you need a way of making sure that you are up to date with the
global state (in one of several senses) before you continue execution, and
acquire/release semantics are a very convenient synchronization model.

Consider Double-Checked Locking
I used DCL with explicit memory barriers to implement thread-safe
initialization of function-local statics
(libstdc++-v3/libsupc++/  The proposed change to volatile
semantics would allow me to write it more simply, by just making the
initialized flag volatile.  Yes, volatile would be stronger than is
actually necessary for DCLP, but I don't have to use it if I want
finer-grained control over the synchronization.

> Seems to me that if C++ is all of the sudden interested in
> dictating memory semantics for threaded programs, it should also
> provide language capabilities for other synchronization models
> and for threads (as in Java, though the memory model of Java used
> to have problems of its own, dunno if they've been fixed).

I believe the plan is to offer library functions which provide
finer-grained control over synchronization primitives, but that volatile
would be good enough for most uses, and easy to teach.

> Anything else will only be an incomplete specification.
> Particularly if it dictates stronger semantics on 'volatile',
> which has been long used in chaotic situations where you either
> don't care about synchronization or are doing it explicitly.

The main reason I posted this now was to get more information about current
uses of volatile, so I can block this proposal in the committee if
necessary.  I find it hard to believe that volatile is currently used in
multithreaded code in ways that would be negatively impacted by this
change, but I'm very interested in examples.

The device driver case seems like a more plausible objection to me, but I'd
like to see an example there, too.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]