[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/5] lock-guard: add scoped lock implementation
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH 2/5] lock-guard: add scoped lock implementation |
Date: |
Fri, 8 Dec 2017 14:12:18 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
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
[Qemu-devel] [PATCH 3/5] qemu-timer: convert to use lock guards, Paolo Bonzini, 2017/12/08
[Qemu-devel] [PATCH 4/5] qht: convert to use lock guards, Paolo Bonzini, 2017/12/08
[Qemu-devel] [PATCH 5/5] thread-pool: convert to use lock guards, Paolo Bonzini, 2017/12/08