Subj : Re: posix and lock-free algorithms To : comp.programming.threads From : David Schwartz Date : Sat Aug 13 2005 02:41 am "David Hopwood" wrote in message news:1laLe.2323$le3.1380@fe1.news.blueyonder.co.uk... > David Schwartz wrote: >> The whole premise of this thread was that we were ignoring this >> paragraph. > If the paragraph is ignored, then what replaces it in order to specify > the semantics of the concurrent accesses that were previously undefined? Nothing. In other words, nothing special happens when this occurs, but no guarantees that are provided by the standard are allowed to be violated. In other words, with this paragraph, after a concurrent read/write to some area of memory, all system calls can fail, or the program can crash. With this paragaph, with a concurrent read/write of a type known to be atomic, either the previous value or the new value is read, and nothing blows up. (We were also assuming you have a pointer type that you know to be atomic.) > POSIX is able to (just about) get away with not defining a memory model, > only because this paragraph effectively hides the differences between > plausible memory models. That is, given that programs with data races > have undefined behaviour, models such as sequential consistency, release > consistency, etc. coincide for other programs. Exactly. > Without this paragraph or any replacement, the specification would be > simply incoherent. No, it wouldn't. All its other guarantees would apply, but concurrent read/writes for atomic types would be defined to provide either the previous or new values and not to violate any other guarantees. POSIX does not and cannot provide this because it has to support platforms where there are no global memory barriers or are no atomic types. However, we are premising that there are atomic types that can tolerate concurrents reads and writes. Obviously, without at least this, DCL is pretty much impossible. DS .