Richard Henderson <[EMAIL PROTECTED]> writes: | On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote: | > 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. | | Is there any reason to want to overload volatile for this, rather than | | template<classname T> T acquire(T *ptr); | template<classname T> void release(T *ptr, T val); | | where the functions do the indirection plus the memory ordering?
My understanding what that some compilers may do "speculative register promotion". (I think the example given by Hans actually involved lock()/unlock() not acquire/release). | The biggest problem that I see is that C and C++ have been around far | too long, and there are far too many existing uses of "volatile" to be | redefining it now. That is a legitime concern that was raised. I think examples of cases that would be inadvertently affected would be very helpful. -- Gaby
