[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations
From: |
Jamie Lokier |
Subject: |
Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations |
Date: |
Wed, 19 Sep 2012 14:16:14 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Avi Kivity wrote:
> On 09/13/2012 09:54 AM, liu ping fan wrote:
>
> >>> +typedef struct Atomic {
> >>> + int counter;
> >>> +} Atomic;
> >>
> >> Best to mark counter 'volatile'.
> >>
> >>> +
> >>> +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.
Hi,
I don't think volatile makes any difference to reordering here.
The compiler is not going to move the atomic_set() store before or
after another instruction on the same atomic variable anyway, just
like it wouldn't do that for an ordinary assignment.
If you're concerned about ordering with respect to other memory, then
volatile wouldn't make much difference. barrier() before and after would.
If you're copying Linux's semantics, Linux's atomic_set() doesn't
include any barriers, nor imply any. atomic_read() uses volatile to
ensure that each call re-reads the value, for example in a loop.
(Same as ACCESS_ONCE()). If there was a call to atomic_set() in a
loop, it doesn't guarantee that will be written each time.
-- Jamie
- [Qemu-devel] [PATCH V3 0/10] prepare unplug out of protection of global lock, Liu Ping Fan, 2012/09/11
- [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, Liu Ping Fan, 2012/09/11
- Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, Avi Kivity, 2012/09/11
- Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, liu ping fan, 2012/09/13
- Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, Avi Kivity, 2012/09/13
- Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, Paolo Bonzini, 2012/09/13
- Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, Avi Kivity, 2012/09/13
- Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, Paolo Bonzini, 2012/09/13
- Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, liu ping fan, 2012/09/13
- Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations,
Jamie Lokier <=
- Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, Jamie Lokier, 2012/09/19
- Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, Peter Maydell, 2012/09/19
- Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, Jamie Lokier, 2012/09/19
Re: [Qemu-devel] [PATCH V3 01/11] atomic: introduce atomic operations, Peter Maydell, 2012/09/11
[Qemu-devel] [PATCH V3 02/11] qom: apply atomic on object's refcount, Liu Ping Fan, 2012/09/11
[Qemu-devel] [PATCH V3 03/11] hotplug: introduce qdev_unplug_complete() to remove device from views, Liu Ping Fan, 2012/09/11
[Qemu-devel] [PATCH V3 04/11] pci: remove pci device from mem view when unplug, Liu Ping Fan, 2012/09/11
[Qemu-devel] [PATCH V3 05/11] memory: introduce ref, unref interface for MemoryRegionOps, Liu Ping Fan, 2012/09/11