CODEWITHSUNDEEP
c++c++17
q0987
q0987

Reputation: 35982

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

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.

Upvotes: 4

Views: 7474

Answers (2)

T.C.
T.C.

Reputation: 137320

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.

Upvotes: 5

Howard Hinnant
Howard Hinnant

Reputation: 218750

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.

Upvotes: 4

Related Questions