On Tue, Dec 15, 2015 at 3:18 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > 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?
There is no such a fast path if we force every CPU to exit the TB and flush the TLB. I though that with "fast path" you were referring to a slow path forced through TLB_EXCL, sorry. alvise > > 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
