Skip to content

Use raii lock in DownloadBucketsWork #4675

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 26, 2025
Merged

Conversation

SirTyson
Copy link
Contributor

Description

Resolves #4674

Note that we are still using lock/unlock at DownloadBucketsWork.cpp:97, given that the type definition is incredibly verbose to forward declare, and it's unlikely std::map::emplace will throw. Even if it does, it doesn't matter that we hold the lock since core and the DownloadBucketsWork will crash anyway.

Checklist

  • Reviewed the contributing document
  • Rebased on top of master (no merge commits)
  • Ran clang-format v8.0.0 (via make format or the Visual Studio extension)
  • Compiles
  • Ran all tests
  • If change impacts performance, include supporting evidence per the performance document

@SirTyson SirTyson requested a review from anupsdf March 26, 2025 17:44
Copy link
Contributor

@anupsdf anupsdf left a comment

Choose a reason for hiding this comment

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

lgtm

@SirTyson SirTyson enabled auto-merge March 26, 2025 17:53
@SirTyson SirTyson added this pull request to the merge queue Mar 26, 2025
@greg7mdp
Copy link

Note that we are still using lock/unlock at DownloadBucketsWork.cpp:97, given that the type definition is incredibly verbose to forward declare

Not sure what C++ version core is using, but you shouldn't have to provide the type to std::lock_guard.

@SirTyson
Copy link
Contributor Author

Note that we are still using lock/unlock at DownloadBucketsWork.cpp:97, given that the type definition is incredibly verbose to forward declare

Not sure what C++ version core is using, but you shouldn't have to provide the type to std::lock_guard.

I'm referring to the type returned by emplace, which must be assigned in the scope of the lock_guard but live outside the lock_guard scope.

@anupsdf
Copy link
Contributor

anupsdf commented Mar 26, 2025

Not sure what C++ version core is using

stellar-core is on C++17, https://github.com/stellar/stellar-core/blob/v22.2.0/configure.ac#L229

@greg7mdp
Copy link

I'm referring to the type returned by emplace, which must be assigned in the scope of the lock_guard but live outside the lock_guard scope.

Got it. You could use a lambda:

    auto [indexIter, inserted] = [&]() {
       std::lock_guard g(mIndexMapMutex);
       return mIndexMap.emplace(currId, nullptr);
    }();

Merged via the queue into stellar:master with commit ea40336 Mar 26, 2025
13 checks passed
@SirTyson SirTyson deleted the raii-lock branch March 26, 2025 20:19
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.

Use RAII-style mechanism for owning a mutex in a scoped block
3 participants