Subj : Re: posix and lock-free algorithms To : comp.programming.threads From : David Schwartz Date : Thu Aug 11 2005 07:11 pm "Joe Seigh" wrote in message news:WIWdnSwafL7Ma2bfRVn-qw@comcast.com... > You're reading into "synchronize memory" more than may really be there. I don't think so. I think the only reasonable way to interpret "synchronize memory" is at least a global read/store barrier. > Nobody > is saying it doesn't have some sort of effect. It's just not clear what > that > effect is and how it manifests itself. I agree, but if it didn't at least prevent stores and loads from being reordered across it as seen by another thread with a similar function, it could not be said to "synchronize memory". > I notice there is tendency for some people to define semantics in terms of > some > arbitrary implementation and confusing one with the other. So for > example, if > the only way you knew of to implement a lock was with memory barriers then > you > might think that locks are defined as having memory barriers. I'm not doing that. I'm saying, in the absence of any other wording, there is no plausible understanding of "synchronize memory" except that at least loads and stores aren't reordered. More might be needed on platforms where there are other ways memory can be unsychronized. POSIX, properly, does not say in detail what it takes to synchronize memory or what it means because that is an implementation detail. If there is no caching, no speculative reads, no delayed writes, "synchronize memory" might mean nothing at all. DS .