[Openmp-commits] [PATCH] D77609: [OpenMP] Added the support for unshackled task in RTL

[Andrey Churbanov via Phabricator via Openmp-commits]

AndreyChurbanov added a comment.

The idea looks feasible to me in general.

Major unclear points off the top of my head are:

- The implementation behavior is not yet defined by the specification, so it will in any way be pilot implementation. Or are you trying it to help the specification progress?

- "For now all tasks are unshackled" - good. But to me this looks like a central point of implementation. What tasks should/can be given to unshackled threads? Is it user's decision, or runtime decision, or some combination (suggest new clause/hint?)? If such a task produce another tasks what to do with them (which thread to push them to, which team should execute them)?  Tasks may have dependencies, affinity, priority,  what to do with them? Should we exclude them from unshackled threads, or have some heuristics here as well?  Etc.

Regarding platform (in)dependence, we do have the implementation of monitor thread, similar technique can be used for the unshackled master thread. And it could not only sleep on condition variable forever, but do some periodic bookkeeping for its team, e.g. to support various wait policies.

Also the question can be for a parent of the task delegated to unshackled thread.  Parent-child relation has some bookkeepings those should not be broken.

- Andrey


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77609/new/

https://reviews.llvm.org/D77609