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.