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.
Those algorithms will not appreciate the fact that 'volatile' is now inserting unnecessary (and unwanted) synchronization that is hidden from the programmer. 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). 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. Diego.
