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 load-acquire. Paolo
signature.asc
Description: OpenPGP digital signature
