Subj : Re: posix and lock-free algorithms To : comp.programming.threads From : Joe Seigh Date : Fri Aug 12 2005 08:45 am David Schwartz, sensing the danger he's in, further qualifies his argument: > "Joe Seigh" wrote in message > news:QdidnQeCm57An2HfRVn-uw@comcast.com... > > >>I think it would depend on the particular function what "synchronize >>memory" >>means. I can think of some implementations where some of the Posix >>functions >>would be a no op and allow memory accesses to be reordered by the compiler >>and or hardware. > > > I don't think it's at all reasonable to say that a function > "synchronizes memory" if memory accesses can be reordered around it (as seen > by another CPU that also uses a function that is required to "synchronize > memory"). In fact, I find this position totally unreasonable. > "as seen by" huh? :) Depending on usage and size constraints, an implementation could optimize a lock with a k-word compare and swap or with transactional memory possibly (someone at Sun let slip a hint that Sun is coming out with this I think). In that case the lock operation becomes a nop and the compiler and hardware can reorder around the no-oped lock operation subject to it's being a branch target for any retries that might be needed. As another example, I just did an RCU+SMR implementation where the requirement for memory barriers in the hazard pointer load are eliminated yet things are still synchronized correctly even with hardware reordering of the hazard pointer load instructions. I do not think that word means what you think it means. :) -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software. .