On Wed, Nov 11, 2009 at 01:01:03PM +0000, Paul Brook wrote: > On Wednesday 11 November 2009, Michael S. Tsirkin wrote: > > On Wed, Nov 11, 2009 at 01:34:12AM +0000, Paul Brook wrote: > > > On Monday 26 October 2009, Michael S. Tsirkin wrote: > > > > wmb must be at least a compiler barrier, even without SMP. > > > > > > Why? > > > > Because virtio code might run on a separate thread from guest. > > If compiler reorders writes, guest might see inconsistent data. > > If you've got threads running in parallel (which may be running on separate > CPUs)
Yes, but you asked what happens without SMP (single CPU). > then you need an actual memory barrier to prevent the hardware > reordering things behind your back. > > If you've already used locking to avoid simultaneous execution then the > locking routines already include memory barriers. You can not share a lock with guest. > A "compiler memory barrier" provides absolutely no guarantees in a > multithreaded environment. They are sometimes useful in a single threaded > interruptable system (i.e. UNIX signals), but that's definitely not the case > here. > > Paul "absolutely no guarantees" is surely wrong. On intel CPUs, regular memory writes are never re-ordered by the CPU. Only compiler can reorder such writes. So yes, on this platform a "compiler barrier" does provide necessary and sufficient guarantees agains write reordering in a multithreaded environment, both with and without SMP. -- MST
