On 12/08/2017 11:56 AM, Paolo Bonzini wrote:
>>> +typedef void QemuLockGuardFunc(void *);
>>> +typedef struct QemuLockGuard {
>>> + QemuLockGuardFunc *p_lock_fn, *p_unlock_fn;
>>> + void *lock;
>>> + int locked;
>>
>> bool?
>
> Yes.
>
>>> +#define QEMU_WITH_LOCK(type, name, lock)
>>> \
>>> + for (QEMU_LOCK_GUARD(type, name, lock);
>>> \
>>> + qemu_lock_guard_is_taken(&name);
>>> \
>>> + qemu_lock_guard_unlock(&name))
>>
>> I don't understand the need for the qemu_lock_guard_is_taken(&name)
>> condition, why not do the following?
>>
>> for (QEMU_LOCK_GUARD(type, name, lock);
>> ;
>> qemu_lock_guard_unlock(&name))
>
> Because that would be an infinite loop. :)
Do we really need 'locked' to belong to the lockguard, just for our use
in for loops? Or can we just declare it in the for loop proper, as in
#define QEMU_WITH_LOCK(type, name, lock) \
for (bool name##_done = false, QEMU_LOCK_GUARD(type, name, lock); \
!name##_done; \
name##_done = true)
and let the automatic scope exit at the conclusion of the one-shot loop
thus unlock things on our behalf, and now we don't have to futz around
with guard->locked everywhere else?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
