Subj : Re: Memory visibility and MS Interlocked instructions To : comp.programming.threads From : David Hopwood Date : Sun Aug 28 2005 12:44 am Joe Seigh wrote: > David Hopwood wrote: >> Joe Seigh wrote: >>> >>> I'm trying to avoid being blindsided by Intel/AMD who seem to have >>> almost no awareness of what's going on in synchronization. >> >> Hey, that's not fair. Intel and AMD's documentation clearly do *not* >> guarantee anything about dependent loads. If it breaks, tough. This is >> no different from any other implementation-defined behaviour. I see no >> reason why Intel or AMD should be constrained to continue to support >> every random property of their current processor models that some bunch >> of hackers might rely on without any justification from the docs. > > The Linux kernel developers are a bunch of hackers? :) They'd tell you so themselves ;-) > Actually, no one is relying on it to work. That's what > the wrapper macros are for. They let you add a membar if > the implementation dependent stuff breaks. But it would be ironic > if Intel inadvertently breaks the very stuff people are > using to make multi-core processors more scalable. We're > just trying to save Intel from themselves. It's not a > correctness of implementation issue, it's a performance > of implementation issue. That's not clear at all. If dependent loads break, some lfence instructions will have to be added. But they will only have to be added in places where the code is actually relying on a load-load constraint, whereas the current semantics (whatever they are :-) potentially affect the performance of *every* load. If Intel or AMD broke dependent loads, I assume it would be because they'd benchmarked the change and found that there was a significant performance gain. I don't know what the ratio of all loads to membars is, but it's got to be very high, so just a tiny improvement in performance due to relaxing the constraints on loads *could* vastly outweigh the cost of the added lfences. -- David Hopwood .