shared_lock
and shared_mutex.lock_shared()
other than that the destructor of shared_lock
unlocks the
shared_mutex.lock_shared()
is a function call that locks shared_mutex
in a shared mode, while shared_lock
is a "lock-class" that is used to lock and automatically unlock mutex at the end of the scope.
No, you can use shared_lock
with any type that meets the SharedMutex requirements.
Always use lock_guard
unless you need additional functionality of unique_lock
. This way your intent is more clear.
This does not depend on shared_lock
or unique_lock
, but on what SharedMutex
you are using. Exact beheavior is not specified by the standard. But here are some clues:
shared_lock
will usually be implemented using SRWLOCK
and tries to be fair e.g. will try to balance readers and writers. No one will have higher priority here.shared_mutex
will most likely be implemented on top of pthread_rwlock_t
and implementations usually give preference to readers because of its requirement to support recursive read locks.shared_mutex
tries to be fair and gives no preference to either side.With reader-preferring shared_mutex
it is possible for your writer thread to never acquire the lock if there is always at least one reader holding it.