qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC v6 00/14] Slow-path for atomic instruction translation
Date: Tue, 15 Dec 2015 15:18:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]