Subject: [SG10] Shared locking
From: Nelson, Clark (clark.nelson_at_[hidden])
Date: 2014-03-17 16:46:17
I've looked into the situation concerning shared_mutex, and it's a bit of a
In the first place, it appears that N3659 doesn't propose any new
functionality in the <mutex> header; everything that's new is in the new
<shared_mutex> header. So there doesn't seem to be any solid rationale
supporting the published recommendation (i.e.
#define __cpp_lib_shared_mutex 201304
I guess we were all counting on Howard to catch errors, and I guess at
that point Howard didn't understand the approach well enough to detect the
error. In some ways, one of the more interesting questions is, considering
the importance of stability of the recommendations, what should be done with
that specific recommendation?
But then along came N3891, and renamed the shared_mutex class. That's
clearly the sort of change that could benefit from a feature-test.
FWIW, here's the current state of the draft on my system:
Shared locking in C++
A proposal to rename shared_mutex to shared_timed_mutex
The __has_include test definitely needs to be there. I left in the 201304
test mainly just for stability reasons, but I moved it from the <mutex>
header to the <shared_mutex> header. I added the 201402 test to
<shared_mutex>; that's exactly right. But it's not so clear to me what macro
name should be used for that test.
So I reached that state more or less by accident, but I have to say that
it's actually kind of attractive to me. The 201304 test is pretty much
superfluous, but the more seriously we take stability, the stronger the
argument for leaving it in. And we would effectively be recommending that
all implementers explicitly indicate which version of the interface they
provide -- which may be helpful, considering the volatility of the
SG10 list run by herb.sutter at gmail.com