[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to tri

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy
Date: Mon, 30 Mar 2015 10:19:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 23/03/2015 03:20, David Gibson wrote:
>>> 1) There's no barrier after the write, so there's no guarantee
>>> the other thread will eventually see it (in practice we've got
>>> other pthread ops we take so we will get a barrier somewhere,
>>> and most CPUs eventually do propagate the store).
> Sorry, I should have been clearer.  If you need a memory barrier,
> by all means include a memory barrier.  But that should be
> explicit: atomic set/read operations often include barriers, but
> it's not obvious which side will include what barrier.

Memory barriers are not needed here.  The variable is set
independently from every other set.  There's no ordering.

atomic_read/atomic_set do not provide sequential consistency.  That's
ensured instead by atomic_mb_read/atomic_mb_set (and you're right that
it's not obvious which side will include barriers, so you have to use
the two together).

>>> 2) The read side could legally be optimised out of the loop by
>>> the compiler. (but in practice wont be because compilers won't
>>> optimise that far).
> That one's a trickier question.  Compilers are absolutely capable
> of optimizing that far, *but* the C rules about when it's allowed
> to assume in-memory values remain unchanged are pretty
> conservative.  I think any function call in the loop will require
> it to reload the value, for example.  That said, a (compiler only)
> memory barrier might be appropriate to ensure that reload.

That's exactly what atomic_read provides.


reply via email to

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