Re: [Qemu-devel] [RFC v6 00/14] Slow-path for atomic instruction translation

[alvise rigo]

On Tue, Dec 15, 2015 at 3:18 PM, Paolo Bonzini <address@hidden> 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