C++11 introduced std::mutex
and its extended version - std::timed_mutex
.
However, in c++14 we have std::shared_timed_mutex
, but its 'parent', the std::shared_mutex
is going to be added in c++17.
Is there any reasonable explanation for that?
If I'm not going to use 'timed' functionality of std::shared_timed_mutex
, is it going to be worse (slower, consuming more resources) than proposed std::shared_mutex
?
The shared_mutex class is a synchronization primitive that can be used to protect shared data from being simultaneously accessed by multiple threads.
The class shared_lock is a general-purpose shared mutex ownership wrapper allowing deferred locking, timed locking and transfer of lock ownership. Locking a shared_lock locks the associated shared mutex in shared mode (to lock it in exclusive mode, std::unique_lock can be used)
Shared mutexes are usually used in situations when multiple readers can access the same resource at the same time without causing data races, but only one writer can do so.
Shared mutex originally had timing in it, and was called shared_mutex
.
An implementor (msvc iirc) noted they could implement it "cheaper" without timing. In particular, SRWLOCK
is an existing primitive on windows that is sufficient to implement shared mutex, but timed requires extra machinery. (Via @t.c.). (However, I believe it isn't just easier because already written, but also fundamentally more expensive, at least on x86/64 windows)
It was too late to add a new type to the standard, but not too late to rename it.
So it was renamed to shared_timed_mutex
, and the untimed version added in next standard.
Here is at least one of the papers involved in the rename.
We propose to rename shared_mutex to shared_timed_mutex:
(a) for consistency with the other mutexes (fixing naming inconsistency);
(b) to leave room for a shared_mutex which can be more efficient on some platforms than shared_timed_mutex.
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