On 08/01/2017 02:05 AM, John Ferlan wrote:
v1: https://www.redhat.com/archives/libvir-list/2017-July/msg01313.html
Differences from v1:
* Use the names virObjectRWLockRead, virObjectRWLockWrite and virObjectRWUnlock
* Instead of an 'int' return, make the virObjectRWLock{Read|Write} be void returns just like virObject{Lock|Unlock}
* Separate out the magic number check for the virObjectIsClass consumers into its own patch and describe the reasons for usage.
* Apply the same magic number check to virObject{Ref|Unref} separately.
BTW: This looks and works eally nice with what I have for common objects...
John Ferlan (8): util: Rename virObjectLockRead to virObjectRWLockRead util: Introduce and use virObjectRWLockWrite util: Only have virObjectLock handle virObjectLockable util: Introduce virObjectGetRWLockableObj util: Introduce and use virObjectRWUnlock util: Create common error path for invalid object util: Add magic number check for object validity util: Add object checking for virObject{Ref|Unref}
src/conf/virdomainobjlist.c | 62 ++++++++-------- src/libvirt_private.syms | 4 +- src/util/virobject.c | 169 +++++++++++++++++++++++++++++++++----------- src/util/virobject.h | 10 ++- 4 files changed, 169 insertions(+), 76 deletions(-)
Okay, I've ran some local tests and indeed no tool showed any misbehaviour when my test binary was mutex-locking an RW lock or rwlocking a mutex. While I still believe that us, reviewers have to be careful around locks anyway, rename to virObjectRWLock* can help us remember if we forget. ACK series. Michal