[libvirt] [PATCH 5/7] util: Introduce and use virObjectRWUnlock

Michal Privoznik mprivozn at redhat.com
Mon Jul 31 08:26:55 UTC 2017


On 07/28/2017 07:07 PM, Pavel Hrdina wrote:
> On Fri, Jul 28, 2017 at 12:38:59PM -0400, John Ferlan wrote:
>> Rather than overload virObjectUnlock as commit id '77f4593b' has
>> done, create a separate virObjectRWUnlock API that will force the
>> consumers to make the proper decision regarding unlocking the
>> RWLock's. This restores the virObjectUnlock code to using the
>> virObjectGetLockableObj as well.
>>
>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>> ---
>>  src/conf/virdomainobjlist.c | 36 ++++++++++++++++++------------------
>>  src/libvirt_private.syms    |  1 +
>>  src/util/virobject.c        | 41 +++++++++++++++++++++++++++--------------
>>  src/util/virobject.h        |  4 ++++
>>  4 files changed, 50 insertions(+), 32 deletions(-)
> 
> The virObjectLockRead and virObjectLockWrite should be probably renamed
> to virObjectRWLockRead and virObjectRWLockWrite for consistency with the
> virObjectRWUnlock.
> 
> Reviewed-by: Pavel Hrdina <phrdina at redhat.com>

This is where I disagree. While you may dislike lock() polymorphism,
unlock() is used widely in literature for both mutexes and RW locks. And
it makes sense because they are fundamentally the same. I'm not going to
NACK this patch only because I find it impolite.

Michal




More information about the libvir-list mailing list