Skip to content

Use std::lock_guard for exception safety in ThreadSafeMap and ThreadSafeQueue#157

Merged
davideberly merged 1 commit intodavideberly:masterfrom
CodeReclaimers:fix/thread-safe-lock-guard
Feb 28, 2026
Merged

Use std::lock_guard for exception safety in ThreadSafeMap and ThreadSafeQueue#157
davideberly merged 1 commit intodavideberly:masterfrom
CodeReclaimers:fix/thread-safe-lock-guard

Conversation

@CodeReclaimers
Copy link
Contributor

Summary

  • All methods in ThreadSafeMap.h and ThreadSafeQueue.h used manual mMutex.lock() / mMutex.unlock() instead of RAII
  • If any operation between lock and unlock throws (e.g., copy constructor in value = iter->second, map insertion in mMap[key] = value), the mutex would never be unlocked, causing a deadlock
  • Replaced all manual lock/unlock pairs with std::lock_guard<std::mutex>, which guarantees unlock on scope exit regardless of exceptions

Test plan

This fix is structural (exception-safety improvement). The bug only manifests when a copy/move constructor throws while the mutex is held, which requires a specially crafted throwing type. The behavioral change is that mutex unlock is now guaranteed in all code paths.

Verified that the files compile correctly and the API is unchanged.

🤖 Generated with Claude Code

…afeQueue

All methods used manual mMutex.lock()/mMutex.unlock() instead of RAII.
If any operation between lock and unlock throws (e.g., copy constructor,
map insertion), the mutex would never be unlocked, causing deadlock.

Replaced all manual lock/unlock pairs with std::lock_guard<std::mutex>.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@davideberly davideberly merged commit 7360d5f into davideberly:master Feb 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants