From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8qQg-0001CM-9n for qemu-devel@nongnu.org; Tue, 15 Dec 2015 09:18:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8qQb-0003NN-NO for qemu-devel@nongnu.org; Tue, 15 Dec 2015 09:18:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49509) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8qQb-0003NG-IG for qemu-devel@nongnu.org; Tue, 15 Dec 2015 09:18:09 -0500 References: <1450082498-27109-1-git-send-email-a.rigo@virtualopensystems.com> <566E8CE3.2040104@redhat.com> <566E9751.3020703@redhat.com> From: Paolo Bonzini Message-ID: <5670211A.7070208@redhat.com> Date: Tue, 15 Dec 2015 15:18:02 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v6 00/14] Slow-path for atomic instruction translation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: alvise rigo Cc: mttcg@greensocs.com, Claudio Fontana , QEMU Developers , "Emilio G. Cota" , Jani Kokkonen , VirtualOpenSystems Technical Team , =?UTF-8?Q?Alex_Benn=c3=a9e?= , Richard Henderson On 15/12/2015 14:59, alvise rigo wrote: >> > If we have two CPUs, with CPU 0 executing LL and the CPU 1 executing a >> > store, you can model this as a consensus problem. For example, CPU 0 >> > could propose that the subsequent SC succeeds, while CPU 1 proposes that >> > it fails. The outcome of the SC instruction depends on who wins. > I see your point. This, as you wrote, holds only when we attempt to > make the fast path wait-free. > However, the implementation I proposed is not wait-free and somehow > serializes the accesses made to the shared resources (that will > determine if the access was successful or not) by means of a mutex. > The assumption I made - and somehow verified - is that the "colliding > fast accesses" are rare. Isn't the fast path (where TLB_EXCL is not set) wait-free? This is enough to mess up the theory, though in practice it works. > I guess you also agree on this, otherwise how > could a wait-free implementation possibly work without being coupled > with primitives with appropriate consensus number? It couldn't. :) Paolo