[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH] qemu/virtio: make wmb compiler barrier + commen

From: Paul Brook
Subject: [Qemu-devel] Re: [PATCH] qemu/virtio: make wmb compiler barrier + comments
Date: Wed, 11 Nov 2009 13:01:03 +0000
User-agent: KMail/1.12.2 (Linux/2.6.30-2-amd64; KDE/4.3.2; x86_64; ; )

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) 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.

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 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]