std::shared_mutex with std::shared_lock is reader or writer preferring?

Question

In implementation of reader-writer lock, we can make use of the std::shared_mutex with std::shared_lock and std::lock_guard or std::unique_lock.

Question> Is this new feature writer or reader preferring?

Update based on Andrew's comment

Reference:

  // Multiple threads/readers can read the counter's value at the same time.
  unsigned int get() const {
    std::shared_lock<std::shared_mutex> lock(mutex_);
    return value_;
  }

  // Only one thread/writer can increment/write the counter's value.
  void increment() {
    std::unique_lock<std::shared_mutex> lock(mutex_);
    value_++;
  }

As you can see from above example, I have no control on the reader/writer priority.

Answer 1

It is neither (if implemented properly). Instead readers and writers are chosen to be next by a fair technique. And that is the reason that this characteristic is neither settable in the API, nor specified.

This answer details how that is accomplished.

Answer 2

In practice:

• libc++ always uses the mutex+condition variables technique Howard mentioned, not surprisingly.
• libstdc++ uses pthread_rwlock_t where available, falling back to the algorithm Howard mentioned if it is not. Therefore if pthread_rwlock_t is available, the algorithm used depends on the pthreads implementation. I believe that glibc prefers readers by default.

• MSVC uses Windows SRWLOCK, whose documentation says

  There is no guarantee about the order in which threads that request ownership will be granted ownership; SRW locks are neither fair nor FIFO.