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.
In practice:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With