From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH] libvchan: interdomain communications library Date: Thu, 25 Aug 2011 11:36:59 -0700 Message-ID: <4E56964B.2010108@goop.org> References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov> <1314004557.5010.411.camel@zakaz.uk.xensource.com> <4E554884.1040109@tycho.nsa.gov> <20110825102738.GA79827@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110825102738.GA79827@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: Daniel De Graaf , "xen-devel@lists.xensource.com" , Stefano Stabellini , Ian Campbell , "konrad.wilk@oracle.com" List-Id: xen-devel@lists.xenproject.org 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