On Thu, 14 Apr 2005 16:04:33 -0400, Diego Novillo <[EMAIL PROTECTED]> 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 (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html). I used DCL with explicit memory barriers to implement thread-safe initialization of function-local statics (libstdc++-v3/libsupc++/guard.cc). 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. Jason
