From: Avi Kivity <avi@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
liu ping fan <qemulist@gmail.com>,
Anthony Liguori <anthony@codemonkey.ws>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations
Date: Thu, 13 Sep 2012 11:23:22 +0300 [thread overview]
Message-ID: <505197FA.1060502@redhat.com> (raw)
In-Reply-To: <50519716.5030402@redhat.com>
On 09/13/2012 11:19 AM, Paolo Bonzini wrote:
> Il 13/09/2012 10:14, Avi Kivity ha scritto:
>>>>> >>> +static inline void atomic_set(Atomic *v, int i)
>>>>> >>> +{
>>>>> >>> + v->counter = i;
>>>>> >>> +}
>>>>> >>> +
>>>>> >>> +static inline int atomic_read(Atomic *v)
>>>>> >>> +{
>>>>> >>> + return v->counter;
>>>>> >>> +}
>>>>> >>>
>>>> >>
>>>> >> So these two operations don't get mangled by the optimizer.
>>>> >>
>>> > Browsing linux code and reading lkml, find some similar material. But
>>> > they have moved volatile from ->counter to function - atomic_read().
>>> > As to atomic_read(), I think it need to prevent optimizer from
>>> > refetching issue, but as to atomic_set(), do we need ?
>> I think so, to prevent reordering.
>
> Agreed. Alternatively, stick a barrier() before and after the
> assignment and read.
>
> But I don't really see the point in wrapping atomically-accessed
> variables in a struct.
Preventing accidental naked access (to be reported in patch review as
"wardrobe malfunction").
> Are we going to add a variant for long, a
> variant for pointers, etc.?
template <typename T> ...;
> I already proposed my version of this at
> http://github.com/bonzini/qemu/commit/1b439343.
Atomic operations are sufficiently rare and sufficiently important to
warrant extra effort, so I prefer the explicitly typed variants.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-09-13 8:23 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-11 7:51 [Qemu-devel] [PATCH V3 0/10] prepare unplug out of protection of global lock Liu Ping Fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations Liu Ping Fan
2012-09-11 8:04 ` Avi Kivity
2012-09-13 6:54 ` liu ping fan
2012-09-13 8:14 ` Avi Kivity
2012-09-13 8:19 ` Paolo Bonzini
2012-09-13 8:23 ` Avi Kivity [this message]
2012-09-13 8:29 ` Paolo Bonzini
2012-09-13 8:45 ` liu ping fan
2012-09-19 13:16 ` Jamie Lokier
2012-09-19 13:32 ` Jamie Lokier
2012-09-19 14:12 ` Peter Maydell
2012-09-19 15:53 ` Jamie Lokier
2012-09-11 8:15 ` Peter Maydell
2012-09-13 6:53 ` liu ping fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 02/11] qom: apply atomic on object's refcount Liu Ping Fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 03/11] hotplug: introduce qdev_unplug_complete() to remove device from views Liu Ping Fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 04/11] pci: remove pci device from mem view when unplug Liu Ping Fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 05/11] memory: introduce ref, unref interface for MemoryRegionOps Liu Ping Fan
2012-09-11 8:08 ` Avi Kivity
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 06/11] memory: make mmio dispatch able to be out of biglock Liu Ping Fan
2012-09-11 8:25 ` Avi Kivity
2012-09-11 8:47 ` Avi Kivity
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 07/11] memory: implement e1000's MemoryRegionOps ref/unref Liu Ping Fan
2012-09-11 8:37 ` Avi Kivity
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 08/11] qom: introduce reclaimer to release obj in async Liu Ping Fan
2012-09-11 8:32 ` Avi Kivity
2012-09-11 9:32 ` liu ping fan
2012-09-11 9:37 ` Avi Kivity
2012-09-13 6:54 ` liu ping fan
2012-09-13 8:45 ` Avi Kivity
2012-09-13 9:59 ` liu ping fan
2012-09-13 10:09 ` Avi Kivity
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 09/11] vcpu: make QemuThread as tls to store thread-self info Liu Ping Fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 10/11] vcpu: introduce lockmap Liu Ping Fan
2012-09-11 8:35 ` Avi Kivity
2012-09-11 9:44 ` liu ping fan
2012-09-11 9:54 ` Avi Kivity
2012-09-11 10:04 ` Jan Kiszka
2012-09-11 11:03 ` Avi Kivity
2012-09-11 11:08 ` Jan Kiszka
2012-09-11 12:20 ` Avi Kivity
2012-09-11 12:25 ` Jan Kiszka
2012-09-11 12:30 ` Avi Kivity
2012-09-11 12:35 ` Jan Kiszka
2012-09-11 12:39 ` Avi Kivity
2012-09-19 4:25 ` Peter Crosthwaite
2012-09-19 4:32 ` Edgar E. Iglesias
2012-09-19 4:40 ` Peter Crosthwaite
2012-09-19 7:55 ` Avi Kivity
2012-09-19 11:46 ` Edgar E. Iglesias
2012-09-19 12:12 ` Avi Kivity
2012-09-19 12:17 ` Edgar E. Iglesias
2012-09-19 13:01 ` Igor Mitsyanko
2012-09-19 13:03 ` Avi Kivity
2012-09-19 7:57 ` Jan Kiszka
2012-09-19 13:07 ` Igor Mitsyanko
2012-09-11 9:57 ` Jan Kiszka
2012-09-11 12:24 ` Avi Kivity
2012-09-11 12:41 ` Avi Kivity
2012-09-11 14:54 ` Marcelo Tosatti
2012-09-13 6:55 ` liu ping fan
2012-09-13 6:55 ` liu ping fan
2012-09-13 8:19 ` Avi Kivity
2012-09-17 2:24 ` liu ping fan
2012-09-19 8:01 ` Avi Kivity
2012-09-19 8:36 ` liu ping fan
2012-09-19 9:05 ` Avi Kivity
2012-09-20 7:51 ` liu ping fan
2012-09-20 9:15 ` Avi Kivity
2012-09-21 7:27 ` liu ping fan
2012-09-11 7:51 ` [Qemu-devel] [PATCH V3 11/11] vcpu: push mmio dispatcher out of big lock Liu Ping Fan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=505197FA.1060502@redhat.com \
--to=avi@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=jan.kiszka@siemens.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemulist@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).