16

Since C++17(C++14) we have the std::shared_(timed_)mutex classes. Qt had an analogous class QReadWriteLock for a long time. QReadWriteLock's documentation says:

To ensure that writers aren't blocked forever by readers, readers attempting to obtain a lock will not succeed if there is a blocked writer waiting for access, even if the lock is currently only accessed by other readers. Also, if the lock is accessed by a writer and another writer comes in, that writer will have priority over any readers that might also be waiting.

As this is certainly a reasonable property, I wonder if std::shared_mutex and std::shared_timed_mutex behave in a similar way?

Adrian
  • 987
  • 5
  • 13
  • huh, what made you think I wanted to imply that the meaning of the question is not clear? Anyhow I agree that my answer is non-sense and deleted it – 463035818_is_not_an_ai Aug 29 '19 at 09:32
  • cpp reference doesn't state anything about – provided it doesn't differ from the standard in this respect (haven't looked up), implementation apparently is unspecified. So every compiler might handle it the way it wants. I personally would implement according to first come, first served, that appears the most natural to me... – Aconcagua Aug 29 '19 at 09:42
  • Nowhere in the documentation of [shared_mutex](https://en.cppreference.com/w/cpp/thread/shared_mutex) nor in [shared_timed_mutex](https://en.cppreference.com/w/cpp/thread/shared_timed_mutex) they mention readers/writers priority over locking. The only way to check this is the source code of the implementaiton. – Tony Tannous Aug 29 '19 at 09:43
  • @Tony Well, one could write a little test programme, too. But both would reveal only *your* compiler's implementation. Others might differ... – Aconcagua Aug 29 '19 at 09:44
  • @Aconcagua indeed. – Tony Tannous Aug 29 '19 at 09:46
  • [Standard](http://eel.is/c++draft/thread.sharedtimedmutex.requirements) indeed doesn't seem to specify, unless I overlooked something. – Aconcagua Aug 29 '19 at 09:57
  • If you need an open source reader/writer mutex that prioritizes waiting writers (non-recursive only): https://www.linkedin.com/pulse/mutual-exclusion-c-between-single-writer-thread-multiple-walter-karas/ – WaltK Oct 22 '20 at 05:13

2 Answers2

11

Official C++ Standard doesn't specify the std::shared_mutex policy. Explanation could be found in original N2406 proposal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#shared_mutex_imp) in shared_mutex Reference Implementation section:

A secondary motivation is to explain the lack of reader-writer priority policies in shared_mutex. This is due to an algorithm credited to Alexander Terekhov which lets the OS decide which thread is the next to get the lock without caring whether a unique lock or shared lock is being sought. This results in a complete lack of reader or writer starvation. It is simply fair.

Comparing to QReadWriteLock implementation (that is write-preferring):

To ensure that writers aren't blocked forever by readers, readers attempting to obtain a lock will not succeed if there is a blocked writer waiting for access, even if the lock is currently only accessed by other readers.

That's true for proposal's shared_mutex as well, to make sure writer will not wait forever if new readers are continuing to come.

Also, if the lock is accessed by a writer and another writer comes in, that writer will have priority over any readers that might also be waiting.

That's NOT true for proposal's shared_mutex, readers and writers have equal priorities in this case.

But unfortunately final C++ Standard document doesn't contain this reference implementation. Note that despite the fact GCC contains std::shared_mutex implementation that is based on N2406 reference implementation, but on Linux it's not used by default, it uses pthread_rwlock_t from POSIX threads lib (controlled by _GLIBCXX_USE_PTHREAD_RWLOCK_T option in c++config.h). pthread_rwlock_t can be read-preferring or write-preferring depending on system setup and applied pthread attributes. See related question for details: How to prevent writer starvation in a read write lock in pthreads

Rost
  • 8,779
  • 28
  • 50
7

It isn't specified by the standard.

POSIX doesn't specify how pthread rwlocks must decide which lock request next succeeds, so it would be impossible to implement C++ std::shared_mutex in terms of standard pthreads if it had such a requirement.

As this is certainly a reasonable property

It's certainly a reasonable property, but it's not the only reasonable property.

For example, GLIBC has a pthreads extension allowing you to choose from three rwlock policies: recursive prefer reader, recursive prefer writer and non-recursive prefer writer. Presumably recursive prefer writer isn't the correct choice for all programs.

To ensure that writers aren't blocked forever by readers ...

As an aside, this does nothing to ensure that writers aren't blocked forever by other writers.

The intuitively-perfectly-fair solution is shared-reader-preferred-exclusive-FIFO-ordered-writer, but this is unnecessarily heavyweight for many purposes.

The Qt version may be exactly perfect for Qt's use case, but it is only one point on the light/efficient -- heavy/fair spectrum.

Useless
  • 64,155
  • 6
  • 88
  • 132