[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: David Gibson
Subject: Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy
Date: Tue, 31 Mar 2015 13:23:05 +1100
User-agent: Mutt/1.5.23 (2014-03-12)

On Mon, Mar 30, 2015 at 10:17:06AM +0200, Paolo Bonzini wrote:
> On 19/03/2015 10:33, Dr. David Alan Gilbert wrote:
> >> > But still pointless.  Atomicity isn't magic pixie dust; it only makes
> >> > sense if you're making atomic specific operations that need to be.
> >> > Simple integer loads and stores are already atomic.  Unless at least
> >> > some of the atomic operations are something more complex, there's
> >> > really no point to atomically marked operations.
> > OK, I'll kill it off.
> No, don't.
> And both of you, read docs/atomics.txt.


> "atomic_read() and atomic_set() prevents the compiler from using
> optimizations that might otherwise optimize accesses out of existence
> on the one hand, or that might create unsolicited accesses on the other.
> [...] it tells readers which variables are shared with
> other threads, and which are local to the current thread or protected
> by other, more mundane means."
> atomic_read() and atomic_set() provide the same guarantees as
> ACCESS_ONCE in the Linux kernel.

Ok, having better understood the semantics and intentions of the
atomic_* functions in qemu, I withdraw my objection.  They do seem
like the right primitives for this situation.

David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!

Attachment: pgpWHp0P8jlcO.pgp
Description: PGP signature

reply via email to

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