Skip to content

Conversation

@Erio-Harrison
Copy link
Contributor

Summary

Modernize all mutex locking from C++11's std::lock_guard to C++17's std::scoped_lock.

Changes

Commit 1: Dual-mutex scenarios

Before (C++11 - manual deadlock avoidance):

std::lock(mutex_, other.mutex_);
std::lock_guard<std::mutex> lock1(mutex_, std::adopt_lock);
std::lock_guard<std::mutex> lock2(other.mutex_, std::adopt_lock);

After (C++17 - automatic deadlock avoidance):

std::scoped_lock lock(mutex_, other.mutex_);

Commit 2: Single-mutex scenarios + headers + examples

Before (C++11):

std::lock_guard<std::mutex> lock(mutex_);

After (C++17):

std::scoped_lock lock(mutex_);

references

cppreference: std::scoped_lock
Stack Overflow: std::lock_guard or std::scoped_lock?
SonarSource RSPEC-5997

Copy link
Owner

@jsulmont jsulmont left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey! Thanks for the contribution — the scoped_lock modernization looks good and I'll merge it.

Quick note for future contributions: the standard OSS workflow is:

  1. Fork the repo
  2. Create a feature branch on your fork (e.g., feature/scoped-lock)
  3. Open a PR from your-fork/feature-branch → upstream/main
  4. After merge, sync your fork's main with upstream

Committing directly to your fork's main makes it harder to keep your fork in sync and creates merge noise. Feature branches keep things clean.

No big deal this time — just something to keep in mind!

@jsulmont jsulmont merged commit 59b588d into jsulmont:main Dec 7, 2025
2 checks passed
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