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

Tue Apr 7 14:10:48 PDT 2020

tianshilei1992 added a comment.

Thank Andrey for your valuable comment.

> 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?

That is a good question. The vision of course is to make it part of specification. :-)

> "For now all tasks are unshackled" - good. But to me this looks like a central point of implementation.

Sorry for the unclear here. "All tasks are unshackled" means, if you look at the source code, the flag is always set to 1. Just for debug, no other reason. Basically, unshackled tasks should not impact current regular task, at least before spec says anything different.

> What tasks should/can be given to unshackled threads? Is it user's decision, or runtime decision, or some combination (suggest new clause/hint?)?

That is a good point. For current purpose, it can only be used by compiler. If a `nowait` target is not in any parallel region, an unshackled task will be created by compiler. The motivation is, just for your information in case that you don't know the context, the "unshackled" here means it will not be bound to any parallel region. That is particularly useful for the case I mentioned. Of course it also implies, especially in current implementation design, they're actually implicitly bound to the same outer-most parallel region. Regular task synchronization should NOT work for them, except one special case that the `taskwait` depends on an unshackled task. What's more, since it is not part of spec, it can not be used by users. Of course if it is part of spec in the future, users can decide it and there must be new clause for it.

> 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.

Those are actually good open problems. From my perspective, the task generated by unshackled task should also be unshackled. Dependencies are not problem, same with regular tasks. As for others, maybe we should exclude those parts. Unshackled task is not born to replace regular task. It is a convenient way to write some tasks without wrapping them into a parallel region which is pretty weird. If users require these fancy features, they should go to regular tasks.

> Regarding platform (in)dependence, we do have the implementation of monitor thread, similar technique can be used for the unshackled master thread.

Could you please tell which part is monitor 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.

It might depend on whether we will have various wait polices. :-)

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77609