-
-
Notifications
You must be signed in to change notification settings - Fork 437
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
Adding feature, Range Based Lock #6379
base: master
Are you sure you want to change the base?
Conversation
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferencesYou may notice some variations in coverage metrics with the latest Coverage engine update. For more details, visit the documentation |
Performance test reportHPX PerformanceComparison
Info
Comparison
Info
Comparison
Info
Explanation of Symbols
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add more tests, especially some tests that actually exercise the multi-threaded use of the new constructs?
class RangeLock | ||
{ | ||
template <typename Key, typename Value> | ||
using MapTy = boost::container::flat_map<Key, Value>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please use names conforming to our naming scheme requirements? In this case, please use map_type
or similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, we do have a flat_map
in HPX, could you use that instead (see: https://github.com/STEllAR-GROUP/hpx/blob/master/libs/core/datastructures/include/hpx/datastructures/detail/flat_map.hpp)
std::size_t lock(std::size_t begin, std::size_t end); | ||
std::size_t try_lock(std::size_t begin, std::size_t end); | ||
void unlock(std::size_t lockId); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually, mutex types are movable, but not copyable. Could you please make sure to conform to the conventions? This will most likely also allow to replace the std::shared_ptr<std::atomic_bool>
with a simpler solution based on unique_ptr
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually, mutex types are movable, but not copyable.
Sure, just need to delete the copy constructor and define a move constructor for it I believe. Do I need to worry about thread safety while moving? like say another thread trying to lock?
This will most likely also allow to replace the std::shared_ptrstd::atomic_bool with a simpler solution based on unique_ptr.
I am unsure how adding move constructor would help change the flag from shared_ptr
to unique_ptr
.
To summarise, if a thread locks range [0, 20), it also creates an atomic_bool
flag.
So if another thread (2) wants to lock an intersecting range, say [10, 30). It spins on the atomic_bool
flag before trying to acquire the lock again, trying to acquire the range_lock is an expensive operation which we want to avoid unless we are confident the range_lock can be acquired.
When performing unlock, we delete the atomic_bool flag while the other threads might still be spinning on it, using unique_ptr
would delete the atomic_bool causing a segmentation fault, shared_ptr
will not cause this issue.
libs/core/synchronization/include/hpx/synchronization/detail/range_lock_impl.hpp
Outdated
Show resolved
Hide resolved
libs/core/synchronization/include/hpx/synchronization/detail/range_lock_impl.hpp
Outdated
Show resolved
Hide resolved
libs/core/synchronization/include/hpx/synchronization/detail/range_lock_impl.hpp
Outdated
Show resolved
Hide resolved
libs/core/synchronization/include/hpx/synchronization/detail/range_lock_impl.hpp
Outdated
Show resolved
Hide resolved
libs/core/synchronization/include/hpx/synchronization/range_lock.hpp
Outdated
Show resolved
Hide resolved
libs/core/synchronization/include/hpx/synchronization/range_lock.hpp
Outdated
Show resolved
Hide resolved
libs/core/synchronization/include/hpx/synchronization/detail/range_lock_impl.hpp
Outdated
Show resolved
Hide resolved
libs/core/synchronization/include/hpx/synchronization/range_lock.hpp
Outdated
Show resolved
Hide resolved
More comprehensive tests on the way @hkaiser. Will add them soon. |
libs/core/synchronization/include/hpx/synchronization/range_mutex.hpp
Outdated
Show resolved
Hide resolved
libs/core/synchronization/include/hpx/synchronization/range_mutex.hpp
Outdated
Show resolved
Hide resolved
libs/core/synchronization/include/hpx/synchronization/range_mutex.hpp
Outdated
Show resolved
Hide resolved
@Johan511 I know that currently the reporting of the build logs for the HPX CIs is broken (we're working on fixing this). For this reason, here is the error message that makes the builders fail:
|
Performance test reportHPX PerformanceComparison
Info
Comparison
Info
Comparison
Info
Explanation of Symbols
|
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferencesYou may notice some variations in coverage metrics with the latest Coverage engine update. For more details, visit the documentation |
range lock impl, spins for wait flag
added header file to cmake added missing headers and return 0 in test added test added test changed file names were not reflected renaming was not committed fixing static errors adding signature to files debugging CI debugging CI forgot header removed debugging logs codacy check change
…_id!=0 throws syystem error fixed codacy warning cleaning up unnecessery template params fixing incorrect std::system_error syntax fixing std::system_error syntax (again) fixing std::system_error syntax (again) changing errc to error_code sys erro trying to fix fixing reorder error Hygiene changes
I have not looked at the implementation (I will examine it later), but I'm curious as to the use case for the range-lock. Is this work inspired by the GSoC project I proposed a few years ago (with an astrophysics particle code in mind), or do you have another use case that requires it? (or perhaps it was "just for fun" as an interesting project to try?) |
@hkaiser can you have a look at the CI? I am not able to view the logs on the jenkins CI. |
Sorry for the CI issues. We're currently working on a solution for this problem. |
Adding feature, Range Based lock to HPX
API:
range_lock rl;
lockId = rl.lock(rangeBegin, rangeEnd);
rl.unlock(lockId);
Pending Task:
Adding tests