Re: [Xen-devel] [PATCH] libvchan: interdomain communications library

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

On 08/25/2011 03:27 AM, Tim Deegan wrote:
> At 14:52 -0400 on 24 Aug (1314197572), Daniel De Graaf wrote:
>> Agreed, barriers are needed for a robust implementation. Since this is
>> a shared library and not xen or kernel code, the existing barrier()/wmb()
>> functions are not available. The only existing implementations in Xen
>> appear to expand to asm("":::"memory") which does not actually implement
>> a memory barrier (i.e. MFENCE or similar opcodes).
> AIUI on x86_64, writes are guaranteed to be seen in order so the only
> thing that barrier has to protect against is the compiler reordering the
> writes.

Yeah, x86 is pretty sane about that stuff.  The main pitfall is that
reads are not necessarily ordered WRT unlocked writes  to different
memory locations, which can bite when you're doing things like:

        shared->locked = 0;
        if (shared->need_wake)
                wake_other();

since "need_wake" can be read before the other side has observed the
"locked = 0".  You can fix it by putting mfence in there, but a sneakier
fix is to make the read overlap the written location, so that the CPU
will force ordering (and ignore the parts you read that you don't want)
- this is much cheaper than an explicit fence.

There are some off-brand x86 implementations which do have out of order
store rules, but nobody has been silly enough to implement SMP systems
with them, and I doubt Xen supports them anyway.  Oh, and there's a PPro
bug which can result in misordered stores, but I think we can overlook
that pretty safely too.

Also I think the various stores which can jump cache levels have weaker
ordering rules, but that shouldn't matter here.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel