Merge bitcoin/bitcoin#32829: threading: use correct mutex name in reverse_lock fatal error messages

de4eef52d123b781b833841a9765d1788010ac6b threading: use correct mutex name in reverse_lock fatal error messages (Cory Fields)

Pull request description:

  "Now that REVERSE_LOCK requires the name of the actual mutex, it can be used for better error messages." - theuni

  This is a follow-up to this comment https://github.com/bitcoin/bitcoin/pull/32465#issuecomment-2981287545

  I just cherry-picked the commit 85c2848eb575f4abaa81fdd4e8f3b2048693dd98

ACKs for top commit:
  theuni:
    Re-ACK de4eef52d123b781b833841a9765d1788010ac6b
  TheCharlatan:
    ACK de4eef52d123b781b833841a9765d1788010ac6b

Tree-SHA512: 1109381e1f0589093f7c737cb1ebd1c43324a9e1ea34b5f05a9171d06ab44cca0c5ead43c581f6e37ded1f0463ab8a280f3319c288d39a4625109b5c08a7cb68
This commit is contained in:
merge-script 2025-07-07 15:51:37 +01:00
commit d33c111448
No known key found for this signature in database
GPG Key ID: 2EEB9F5CC09526C1
2 changed files with 2 additions and 2 deletions

View File

@ -248,7 +248,7 @@ public:
// it is not possible to use the lock's copy of the mutex for that purpose.
// Instead, the original mutex needs to be passed back to the reverse_lock for
// the sake of thread-safety analysis, but it is not actually used otherwise.
#define REVERSE_LOCK(g, cs) typename std::decay<decltype(g)>::type::reverse_lock UNIQUE_NAME(revlock)(g, cs, #g, __FILE__, __LINE__)
#define REVERSE_LOCK(g, cs) typename std::decay<decltype(g)>::type::reverse_lock UNIQUE_NAME(revlock)(g, cs, #cs, __FILE__, __LINE__)
// When locking a Mutex, require negative capability to ensure the lock
// is not already held

View File

@ -54,7 +54,7 @@ BOOST_AUTO_TEST_CASE(reverselock_errors)
g_debug_lockorder_abort = false;
// Make sure trying to reverse lock a previous lock fails
BOOST_CHECK_EXCEPTION(REVERSE_LOCK(lock2, mutex2), std::logic_error, HasReason("lock2 was not most recent critical section locked"));
BOOST_CHECK_EXCEPTION(REVERSE_LOCK(lock2, mutex2), std::logic_error, HasReason("mutex2 was not most recent critical section locked"));
BOOST_CHECK(lock2.owns_lock());
g_debug_lockorder_abort = prev;