This replaces boost::shared_mutex
and boost::unique_lock
with std::shared_mutex
& std::unique_lock
.
Even though some concerns were raised in #16684 with regard to std::shared_mutex
being unsafe to use across some glibc versions, I still think this change is an improvement. As I mentioned in #21022, I also think trying to restrict standard library feature usage based on bugs in glibc is not only hard to do, but it’s not currently clear exactly how we do that in practice (does it also extend to patching out use in our dependencies, should we be implementing more runtime checks for features we are using, when do we consider an affected glibc “old enough” not to worry about? etc). If you take a look through the glibc bug tracker you’ll no doubt find plenty of (active) bug reports for standard library code we already using. Obviously not to say we shouldn’t try and avoid buggy code where possible.
Two other points:
[Cory mentioned in #21022](/bitcoin-bitcoin/21022/#issuecomment-769274179):
It also seems reasonable to me to worry that boost hits the same underlying glibc bug, and we’ve just not happened to trigger the right conditions yet.
Moving away from Boost to the standard library also removes the potential for differences related to Boosts configuration. Boost has multiple versions of shared_mutex
, and what you end up using, and what it’s backed by depends on:
- The version of Boost.
- The platform you’re building for.
- Which version of
BOOST_THREAD_VERSION
is defined: (2,3,4 or 5) default=2. (see here for some of the differences). - Is
BOOST_THREAD_V2_SHARED_MUTEX
defined? (not by default). If so, you might get the “less performant, but more robust” version ofshared_mutex
.
A lot of these factors are eliminated by our use of depends, but users will have varying configurations. It’s also not inconceivable to think that a distro, or some package manager might start defining something like BOOST_THREAD_VERSION=3
. Boost tried to change the default from 2 to 3 at one point.
With this change, we no longer use Boost Thread, so this PR also removes it from depends, the build system, CI etc.
Previous similar PRs were #19183 & #20922. The authors are included in the commits here. Also related to #21022 - pthread sanity checking.