may be unsafe to use, when coupled with a range of glibc versions ~2.26->2.29, which may block our adoption and the removal of Boost Thread.

plugs #18110

Edit: with regard to shared_mutex specifically, these are the only uses, of which one is in the tests:

src/script/sigcache.cpp:#include <boost/thread/shared_mutex.hpp>
src/script/sigcache.cpp:    boost::shared_mutex cs_sigcache;
src/script/sigcache.cpp:        boost::shared_lock<boost::shared_mutex> lock(cs_sigcache);
src/script/sigcache.cpp:        boost::unique_lock<boost::shared_mutex> lock(cs_sigcache);
src/test/cuckoocache_tests.cpp:    boost::shared_mutex mtx;
src/test/cuckoocache_tests.cpp:        boost::unique_lock<boost::shared_mutex> l(mtx);
src/test/cuckoocache_tests.cpp:            boost::shared_lock<boost::shared_mutex> l(mtx);
src/test/cuckoocache_tests.cpp:    boost::unique_lock<boost::shared_mutex> l(mtx);

Can't we get rid of it? That's resolve this particular issue at least (though not the wider discussion around glibc versions).

plugs #18110

I know this is really pushing it, but I don't think it's totally crazy to consider vendoring musl in the very long term (not now).

Certainly building against it for releases is worth considering.

Can't we get rid of it? That's resolve this particular issue at least (though not the wider discussion around glibc versions).

Without looking at the code (assuming it wouldn't require a redesign), this seems like a reasonable temporary punt. 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.

Shared locks are really handy to have sometimes, though, so we'll definitely want a path back to enabling them if we take that route. @fanquake's approach here makes perfect sense to me in that regard.

Can't we get rid of it? That's resolve this particular issue at least (though not the wider discussion around glibc versions).

Without looking at the code (assuming it wouldn't require a redesign), this seems like a reasonable temporary punt.

I think this is actually very reasonable. The shared_mutex in the sigcache was introduced in ef0f422. @sipa's commit log:

Remove contention on signature cache during block validation

Since block validation happens in parallel, multiple threads may be
accessing the signature cache simultaneously. To prevent contention:
* Turn the signature cache lock into a shared mutex
* Make reading from the cache only acquire a shared lock
* Let block validations not store their results in the cache

I believe that since #10192 was merged, block validation will now very rarely use the signature cache. From that PR:

This is somewhat duplicative with the sigcache, as entries in the
new cache will also have several entries in the sigcache. However,
the sigcache is kept both as ATMP relies on it and because it
prevents malleability-based DoS attacks on the new higher-level
cache. Instead, the -sigcachesize option is re-used - cutting the
sigcache size in half and using the newly freed memory for the
script execution cache.

If the only use for sigcache is now in ATMP (which is single-threaded and requires cs_main), then changing this to a simple mutex wouldn't have any impact on performance. I don't understand the "prevents malleability-based DoS attacks on the new higher-level cache" part of @TheBlueMatt's description so I may be missing something subtle here.

Closing this now that #21064 has been merged, however I think there is still scope for us to increase our runtime sanity checks going forward. Will propose some other changes.