Manuel Bouyer wrote:
> On Sun, Mar 27, 2005 at 12:54:48AM +0100, Lennart Augustsson wrote:
> 
>>>This would probablt be a good idea, but isn't __insn_barrier() a
>>>gcc builtin ?
>>
>>Would that really be correct?  I thought __insn_barries() was there
>>to stop gcc from reordering instructions, whereas x86_lfence() is
>>there to stop the processor from reordering loads and stores.
> 
> 
> I think we want a MI function to stop the processor from reordering
> instructions too. There is potentially a similar problem in the esiop(4)
> driver than the one I had with xen. I could abuse bus_space_barrier()
> for this but it's not quite right either.
> 
> If we don't want the compiler to reorder instructions, I don't think we want
> to CPU to do it.

You may want to disallow the compiler to reorder, but allow the CPU to.
E.g., when programming with threads on a single CPU.  The CPU reordering
(on an x86) never changes how the processor sees the memory if it is the
only client of the memory.

So I think there is a case for both.  And yes, of course we want MI ways
of doing it.  There is a whole range of possible fences one can imagine
and they carry different costs depending on the platform.

	-- Lennart