-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Add reference implementation for parallel_phase feature #1570
base: master
Are you sure you want to change the base?
Conversation
@akukanov @aleksei-fedotov @vossmjp Could you please take a look at the PR in terms of implementation and ABI. P.S. Tests are still WIP. |
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.
Not a complete review, just a couple of starters to think about.
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.
A bunch of comments from me. Have not looked at the tests yet. Also, not finished reviewing the PHASE_* switching logic because of found issue.
test/tbb/test_task_arena.cpp
Outdated
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.
In addition, I think need to cover in tests the following:
- The DELAYED_LEAVE is returned back once new task is submitted.
- Here I think we can test that the return of a worker after one-time-fast-leave happens generally longer than the following returns made after new task(s) is/are submitted.
- Nested parallel phases with combinations of DELAYED and (ONE TIME) FAST leaves.
Signed-off-by: pavelkumbrasev <[email protected]>
Signed-off-by: pavelkumbrasev <[email protected]>
Signed-off-by: pavelkumbrasev <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
…rallel_block Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Co-authored-by: Aleksei Fedotov <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Co-authored-by: Aleksei Fedotov <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Co-authored-by: Aleksei Fedotov <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
Signed-off-by: Isaev, Ilya <[email protected]>
b93e59e
to
398d16b
Compare
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.
I think the PR looks good enough as a preview functionality. Consider my other suggestions to ponder on and insignificant remarks. Perhaps, we would be able to "close on" these before fully supporting this feature.
I approve it. Though you might also want implementing Alexey's comment about single fast_leave_policy_flag
as well because suggested in-the-patch approach can be implemented in future if we would ever have more than two leave policies.
Signed-off-by: Isaev, Ilya <[email protected]>
…rena Signed-off-by: Isaev, Ilya <[email protected]>
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.
LGTM
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.
My comments below are not critical; feel free to commit as-is and address later.
bool fast_policy_set = (my_version_and_traits & fast_leave_policy_flag) == fast_leave_policy_flag; | ||
return fast_policy_set ? leave_policy::fast : leave_policy::automatic; |
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.
bool fast_policy_set = (my_version_and_traits & fast_leave_policy_flag) == fast_leave_policy_flag; | |
return fast_policy_set ? leave_policy::fast : leave_policy::automatic; | |
return (my_version_and_traits & fast_leave_policy_flag) ? leave_policy::fast : leave_policy::automatic; |
It's really the same but shorter :)
return fast_policy_set ? leave_policy::fast : leave_policy::automatic; | ||
} | ||
|
||
int leave_policy_to_traits(leave_policy lp) const { |
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.
Rename to leave_policy_trait
?
task_arena(int max_concurrency_ = automatic, unsigned reserved_for_masters = 1, | ||
priority a_priority = priority::normal) | ||
: task_arena_base(max_concurrency_, reserved_for_masters, a_priority) | ||
priority a_priority = priority::normal | ||
#if __TBB_PREVIEW_PARALLEL_PHASE | ||
, leave_policy lp = leave_policy::automatic | ||
#endif |
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.
Indentation seems a bit misaligned.
static const std::uint64_t DELAYED_LEAVE = 1 << 2; | ||
static const std::uint64_t PARALLEL_PHASE = 1 << 3; | ||
|
||
std::atomic<std::uint64_t> my_state{0}; |
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.
Not sure if 64-bit atomic is really needed. Even if it's only 32 bit, 2^29 seems quite enough for the amount of simultaneous parallel phases. The benefit would be better support for 32 bit platforms, but maybe it's negligible.
|
||
std::atomic<std::uint64_t> my_state{0}; | ||
public: | ||
void set_initial_state(tbb::task_arena::leave_policy lp) { |
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.
Since this is essentially the constructor, please add a comment that this method is required to be called soon after construction, and is not thread-safe. Or maybe consider converting it into a real constructor.
} | ||
} | ||
|
||
void restore_default_policy_if_needed() { |
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.
I would just call it reset
(or reset_if_needed
) for better encapsulation.
static const std::uint64_t FAST_LEAVE = 1; | ||
static const std::uint64_t ONE_TIME_FAST_LEAVE = 1 << 1; | ||
static const std::uint64_t DELAYED_LEAVE = 1 << 2; |
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.
In principle, you only need 2 bits, not 3. One bit could be set at construction. indicating "default" fast leave; the other could be set for one-time fast leave. Both bits unset would mean delayed leave. I think that might also simplify the implementation logic.
Description
Add a comprehensive description of proposed changes
Fixes # - issue number(s) if exists
Type of change
Choose one or multiple, leave empty if none of the other choices apply
Add a respective label(s) to PR if you have permissions
Tests
Documentation
Breaks backward compatibility
Notify the following users
List users with
@
to send notificationsOther information