-
Notifications
You must be signed in to change notification settings - Fork 5
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
Prototype for module-internal chain of tasks #363
Prototype for module-internal chain of tasks #363
Conversation
This guarantees proper exception delivery from the function(s) to the WaitingTaskWithArenaHolder.
@vkhristenko this is the PR I mentioned |
@VinInn this mechanism can be used also for "re-running a producer with more memory when initial memory was not sufficient" |
…lities taking just a lambda
holder.doneWaiting(*excptr); | ||
return; | ||
} | ||
func(); |
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'm a bit unhappy about the replication of WaitingTaskWithArenaHolder
here, especially since the code-to-be-copied would be only 4 lines.
Validation summaryReference release CMSSW_10_6_0 at b45186e
|
About the |
Couple of items from a chat with @fwyzard
|
@fwyzard I've addressed the points from our discussion (#363 (comment)), could you take a look again? |
Thanks, the latest set of changes make it clear what the behaviour of the tasks should be. |
The only aspect that it's not clear to me is why
I thought the |
@fwyzard Services are a rather complex subsystem, approximately requiring a valid ServiceToken on the thread calling Services. The framework holds a ServiceToken during the execution of any module methods, but such token does not exist on arbitrary TBB tasks and thus Services can not be used. Here I decided to be lazy and not support Services in these tasks (and see how far we get with it). |
PR description:
This PR adds helpers for a chain of TBB tasks internal to the ExternalWork module. These helpers can be used to implement e.g. a chain of tasks that alternate CPU and GPU work, or a loop of GPU work where the decision of continuing is done in the CPU. This PR also adds
CUDAScopedContextAnalyze
mentioned in #355 (comment).In short, the
CUDAScopedContextAcquire
can be used to queue a "next task" instead of theproduce()
withThe commit 203cd7d experiments with the interface by providing directly the
CUDAScopedContextTask
to the user at the cost of interface inconsistency betweenacquire()
and the functionI would like to hear opinions of others which one would you prefer.
PR validation:
Added test runs.