Address annotation gaps found by concurrency analysis

[marta-lokhova]

No description provided.

[Copilot]

Pull request overview

This PR addresses concurrency analysis gaps by adding thread safety annotations to various classes. The changes convert standard library mutex types to custom wrapper types that support Clang's thread safety analysis, add GUARDED_BY annotations to protected fields, and replace standard lock guards with macro-based equivalents that work with the thread safety analysis framework.

Changes:

• Convert mutexes in VirtualClock, ProcessManagerImpl, and LiveBucketIndex to thread-safety-annotated wrapper types (Mutex, RecursiveMutex, SharedMutex)
• Add GUARDED_BY annotations to fields protected by these mutexes
• Replace std::lock_guard usages with LOCK_GUARD/RECURSIVE_LOCK_GUARD macros
• Document lock ordering between Peer::mStateMutex and Hmac::mMutex using ACQUIRED_BEFORE annotation
• Add thread assertion to LedgerManagerImpl::isApplying()

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/util/Timer.h	Convert VirtualClock mutexes to Mutex type and add GUARDED_BY annotations
src/util/Timer.cpp	Replace std::lock_guard with LOCK_GUARD macro
src/process/ProcessManagerImpl.h	Convert mProcessesMutex to RecursiveMutex and add GUARDED_BY annotations
src/process/ProcessManagerImpl.cpp	Replace std::lock_guard with RECURSIVE_LOCK_GUARD macro
src/overlay/Peer.h	Add ACQUIRED_BEFORE annotation to document lock ordering with Hmac::mMutex
src/overlay/Hmac.h	Expose mMutex as public under THREAD_SAFETY and add GUARDED_BY to fields
src/overlay/Hmac.cpp	Add LOCK_GUARD to damageRecvMacKey test method
src/ledger/LedgerManagerImpl.h	Add thread assertion to isApplying() getter
src/bucket/LiveBucketIndex.h	Convert mCacheMutex to SharedMutex and add GUARDED_BY annotation
src/bucket/LiveBucketIndex.cpp	Replace std::shared_lock/std::unique_lock with SharedLockShared/SharedLockExclusive

[SirTyson]

LGTM, but I think while we're here we can add much better tracy visibility into our locks.

[SirTyson]

LGTM overall! I think if we generate tracy graphs that are too large, we can do a followup where we narrow down our uses of the macro. Imo tracy graphs are already huge and I'd rather have larger traces with full visibility instead of having blind spots when possible. It's a micro-benchmarking tool anyway, so I think we should avoid optimizing for size/noise unless it's really necessary.

Couple small nits, and the macro accidentally upgraded some pre-existing mutexes to mutable. Probably not a big deal, but we can be a little more conservative.

[SirTyson]

Sorry for the delay, LGTM!