This is the mail archive of the
mailing list for the GCC project.
Re: Heads-up: volatile and C++
On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <email@example.com> wrote:
> Jason Merrill wrote:
>> The C++ committee (well, a subgroup represented at this meeting by Hans
>> Boehm) is working on a memory model that supports threaded programs.
> As someone who uses the C++ language and multi-threading
> extensively in embedded systems, I have come to the following
> The language (C++) *should not* have dependencies
> upon threading. IMHO, threading is a layer above a
> systems programming language, and having dependencies
> upon upper layers is evil.
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.
> Since IANALL, but I believe (as obviously you do)
> that changing the semantics of volatile should be
> under-taken with great care.
> I'm not familiar with ia64 barrier instructions, but I
> *am* familiar with PowerPC barrier and synchronization
> instructions (eieio, sync, isync, etc.), and I would
> question the practice of automatically generating
> these as side effect of a variable being declared
> as volatile, if for no other reason than the possible
> presence of code that is unnecessary in some (perhaps
> most) circumstances.
It seems to me that the current specification of volatile already requires
an lwsync around volatile reads and writes, to guarantee that all previous
stores have been completed and later ones have not started.