Ryan Ofsky 5e6dbfd14e
Merge bitcoin/bitcoin#32465: thread-safety: fix annotations with REVERSE_LOCK
a201a99f8cf5ee5af0cd83cb2e1821e455d6eca7 thread-safety: fix annotations with REVERSE_LOCK (Cory Fields)
aeea5f0ec112f9ec29da37806925e961c4998365 thread-safety: add missing lock annotation (Cory Fields)
832c57a53410870471a52647ce107454de3bc69c thread-safety: modernize thread safety macros (Cory Fields)

Pull request description:

  This is one of several PRs to cleanup/modernize our threading primitives.

  While replacing the old critical section locks in the mining code with a `REVERSE_LOCK`, I noticed that our thread-safety annotations weren't hooked up to it. This PR gets `REVERSE_LOCK` working properly.

  Firstly it modernizes the attributes as-recommended by the [clang docs](https://clang.llvm.org/docs/ThreadSafetyAnalysis.html) (ctrl+f for `USE_LOCK_STYLE_THREAD_SAFETY_ATTRIBUTES`). There's a subtle difference between the old `unlock_function` and new `release_capability`, where our `reverse_lock` only works with the latter. I believe this is an upstream bug. I've [reported and attempted a fix here](https://github.com/llvm/llvm-project/pull/139343), but either way it makes sense to me to modernize.

  The second adds a missing annotation pointed out by a fixed `REVERSE_LOCK`. Because clang's thread-safety annotations aren't passed through a reference to `UniqueLock` as one may assume (see [here](https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#no-alias-analysis) for more details), `cs_main` has to be listed explicitly as a requirement.

  The last commit actually fixes the `reverse_lock` by making it a `SCOPED_LOCK` and using the pattern [found in a clang test](https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCXX/warn-thread-safety-analysis.cpp#L3126). Though the docs don't describe how to accomplish it, the functionality was added [in this commit](6a68efc959). Due to aliasing issues (see link above), in order to work correctly, the original mutex has to be passed along with the lock, so all existing `REVERSE_LOCK`s have been updated. To ensure that the mutexes actually match, a runtime assertion is added.

ACKs for top commit:
  fjahr:
    re-ACK a201a99f8cf5ee5af0cd83cb2e1821e455d6eca7
  davidgumberg:
    reACK a201a99f8c
  theuni:
    Ok, done. Those last pushes can be ignored. ACKs on a201a99 are still fresh.
  ryanofsky:
    Code review ACK a201a99f8cf5ee5af0cd83cb2e1821e455d6eca7. Just dropping 0065b9673db5da2994b0b07c1d50ebfb19af39d0 and fixing incorrect `reverse_lock::lockname` initialization since last review.
  TheCharlatan:
    Re-ACK a201a99f8cf5ee5af0cd83cb2e1821e455d6eca7

Tree-SHA512: 2755fae0c41021976a1a633014a86d927f104ccbc8014c01c06dae89af363f92e5bc5d4276ad6d759302ac4679fe02a543758124d48318074db1c370989af7a7
2025-06-17 14:12:43 -04:00
..
2025-05-08 16:49:58 +01:00
2025-05-14 14:00:43 -07:00
2025-05-19 16:40:33 +01:00
2025-05-19 16:40:33 +01:00
2025-03-13 11:13:13 +00:00
2025-05-20 09:30:41 +01:00
2024-11-26 20:47:08 -05:00
2025-05-19 16:40:33 +01:00
2025-05-06 12:21:32 -07:00
2025-05-19 16:40:33 +01:00
2024-11-04 14:19:40 -05:00
2024-05-20 16:48:19 +00:00
2024-07-08 11:12:01 +02:00
2025-06-03 08:09:21 +01:00
2025-05-08 16:49:58 +01:00
2025-06-03 08:09:28 +01:00
2024-12-31 00:04:20 -03:00
2024-12-31 00:04:20 -03:00
2025-05-19 16:40:33 +01:00
2025-04-09 15:59:59 +01:00
2025-04-09 15:59:59 +01:00