qemu-devel
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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