[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