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

[Shilei Tian via Phabricator via Openmp-commits]

tianshilei1992 created this revision.
tianshilei1992 added a reviewer: jdoerfert.
tianshilei1992 added a project: OpenMP.
Herald added subscribers: openmp-commits, guansong, yaxunl, mgorny.
tianshilei1992 edited the summary of this revision.

This patch is just a drafted version to show my design of implementing unshackled task. It contains some problems, like error information is not right, the flag for unshackled task is always set to 1. Will make things right if the design itself is generally right.

The basic design is to create an outer-most parallel team. It is not regular team because it has its own team. We first use `pthread_create` to create a new thread, let's call it the initial and also master thread of unshackled team. This initial thread then initializes a new root, just like what RTL does in initialization. After that, directly call `__kmpc_fork_call`. It is like the initial thread encounters a parallel region. The wrapped function for this team is, for master thread, which is the initial thread that we create via `pthread_create` on Linux, it waits on a condition variable. The condition variable can only be signaled when RTL is deconstructing. For other work threads, they just do nothing. The reason that master thread needs to wait there is, in current implementation, once master thread finishes the wrapped function of this team, it starts to free the team which is not what we want.

Here are some open issues to be discussed:

1. You can see here we still use platform dependent method to create thread. Can we use platform independent way like `std::thread`? The advantage of using C++ thread library is, we don't need to implement same functions for different platforms. One potential reason I can think about is, we cannot set attributes using C++ thread library. We do have some configurations like stack size. Since currently `libomp.so` does not depend on `libc++.so`, using C++ thread library means it has one more dependency. Is it good? In addition to thread creating, others like condition variables, also apply.
2. Synchronization, synchronization, synchronization. What policy should we use for unshackled tasks?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77609

Files:
  openmp/runtime/src/CMakeLists.txt
  openmp/runtime/src/kmp.h
  openmp/runtime/src/kmp_global.cpp
  openmp/runtime/src/kmp_runtime.cpp
  openmp/runtime/src/kmp_tasking.cpp
  openmp/runtime/src/kmp_wait_release.h
  openmp/runtime/src/z_Linux_util.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D77609.255538.patch
Type: text/x-patch
Size: 14687 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-commits/attachments/20200406/20ec5058/attachment-0001.bin>