On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote: > 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. > Again, not always. Consider chaotic asynchronous algorithms (like variations of simulated annealing). They need no locks nor any other kind of synchronization, though sometimes they'll use some form of control synchronization to delimit phases.
When implementing them in a shared-memory multithreaded environment, they typically mark shared data as 'volatile' to prevent the compiler from optimizing those references away. > 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. > Right, but it would take away the traditional semantics of volatile. Why not use some new language construct (monitors, set/wait) or even templates to implement synchronization? That's the only thing that I find disturbing about the proposal. Overloading a very well established keyword with a new meaning. I don't think it's going to be well received, that's all. > 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. > Oh, it's been a while. All the ones that come to mind are relatively obscure research topics. One I remember was from the game theory folks at my old school http://www.cs.ualberta.ca/~jonathan/Grad/Papers/aphidiee.ps There's a somewhat tedious survey of asynchronous parallel techniques at http://web.nchu.edu.tw/~jlu/research/papers/asynch.ps Note that the initial motivation for many of these techniques was to yield good results on distributed systems. But if you were to implement them in a multithreaded environment with shared data instead of message passing, they'd declare the shared data volatile. > The device driver case seems like a more plausible objection to me, but I'd > like to see an example there, too. > Perhaps Windows? I'd think Windows is chok full of device drivers written in C++. Diego.
