[Openmp-commits] [PATCH] D107496: [OpenMP] Fix task wait doesn't work as expected in serialized team

[Shilei Tian via Phabricator via Openmp-commits]

tianshilei1992 added a comment.

In D107496#2927620 <https://reviews.llvm.org/D107496#2927620>, @protze.joachim wrote:

> You are right with your statement, that the two are not completely equivalent. But I still prefer my approach.
>
> Consider the following sequence:
>
>   #pragma omp task detach(e) depend(out:a)
>   {}
>   #pragma omp taskwait depend(in:a)
>   #pragma omp task
>   {}
>
> Your approach will enforce reference counting of child tasks until the end of the parallel region (remember that also `main` has an implicit inactive parallel region!). So, you will in/decrement the counter also for the last task.
>
> My approach will stop reference counting, as soon as no other task is alive in the team and the task is really serialized. The race condition for at `td_allocated_child_tasks>0` and then possibly incrementing from `td_allocated_child_tasks=0` is actually harmless, because the same task will decrement the value at the end of it's execution.

Yes, you're right. Mine will start the counting as long as there is a detached task or hidden helper task found. I'm just thinking if it is possible there is a task that doesn't increment the count when it is allocated but decrements the counter by mistake.

> For a really serialized task (which does no reference counting), no other task can be created during it's execution, so that `td_allocated_child_tasks` cannot be >0 at the end of execution.
> Similar reasoning holds for your approach: for a serialized task, neither of the two flags in task_team can be set while the task executes and they are never set back to 0, aren't they?

Tasks can still be created but whether they are able to deferred, it depends. No?

> The only requirement is, that the same set of flags is checked for the creation and end of task execution; and it is also important, that the values cannot change between the two encountering. I think, we should collect the flags into a macro/function to make sure we keep them symmetric.

I'll wrap them into a function.

> With more and more conditions to this "fast path" for serialized tasks: when does the number of conditions and checks become more expensive than the operations we try to avoid - atomic writes to some variable with no contention?

That's a good point. It might worth a try to see which path is better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107496