Subj : Re: posix and lock-free algorithms To : comp.programming.threads From : David Hopwood Date : Thu Aug 04 2005 04:46 pm John Doug Reynolds wrote: >>Scott Meyers and Andre Alexandrescu wrote a two-part article >>for Dr. Dobbs Journal on this exact subject. >>I found a link to a revised copy here: >>http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf > > Sean, thanks for the article! > > The authors seem to conclude that DCSI could be implemented portably > in C/C++ under Posix, if Posix supported explicit memory barriers. .... and a memory model in which the semantics of explicit memory barriers would be well-defined. That is the more fundamental issue. > They do not discuss constructing a memory barrier from the available > Posix synchronization primitives, or explain why > > void memory_barrier() { mutex m; m.lock(); m.unlock(); } > > does not work for that purpose. "Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it." memory_barrier() [assuming it used a pthreads mutex] doesn't do anything to ensure that this condition is met. > According to David Schwartz, > > "In principle, that could be optimized by a sufficiently smart > implementation to nothing." > > If so, then as you say, it is a language issue, not a failure of Posix > to provide the necessary tools. But I wonder about David's claim. > While it's obvious to the human reader that my function is an > expensive no-op, the compiler has to actually prove this, right? The reason why it's a bad idea to rely on a compiler (or any part of a language implementation) not being smart enough to do a particular optimization is not just that a smart compiler might actually do the optimization. It's that the fact that the optimization could be done points to some more fundamental problem with the approach that assumes it is not done. -- David Hopwood .