On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> 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 > belief/opinion. > > 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. Jason
