[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 02/10] qemu-thread: introduce QemuLockCnt

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 02/10] qemu-thread: introduce QemuLockCnt
Date: Wed, 11 Jan 2017 17:51:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

On 11/01/2017 17:35, Stefan Hajnoczi wrote:
> On Wed, Jan 04, 2017 at 02:26:17PM +0100, Paolo Bonzini wrote:
>> +/* Decrement a counter, and return locked if it is decremented to zero.
>> + * It is impossible for the counter to become nonzero while the mutex
>> + * is taken.
>> + */
>> +bool qemu_lockcnt_dec_and_lock(QemuLockCnt *lockcnt)
>> +{
>> +    int val = atomic_read(&lockcnt->count);
> Why does qemu_lockcnt_inc() use atomic_mb_read() while this function
> uses plain atomic_read()?

qemu_lockcnt_inc can use atomic_read indeed.

In both cases, the actual synchronization happens in atomic_cmpxchg or
qemu_lockcnt_lock.  This is just an "advisory" read to decide what path
to go through.  The worst case that can happen is that you go uselessly
once through the while-cmpxchg loop, or that you don't use the fast path
even though you could have.

In contrast, qemu_lockcnt_dec_if_lock needs atomic_mb_read to do a


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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