You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now, the thread information for each omp task is taken from blocked ULTs. It works from common task patterns but not for nested task codes that start with single or master clauses (like Fibonacci).
The problem is that we are doubling the thread structures including the task queue so when a new omp task is created it can be done in the real threads queue or in the "fake" one. Then, when we try to join the task... we can not be sure where it is.
However, this issue is related to the OpenMP committee decision about if two omp task can be concurrently executed sharing the thread id
The text was updated successfully, but these errors were encountered:
Currently, it turned out it is not correct to run two tasks concurrently with the same thread id because two tasks may access the thread-private data, which should be serialized.
Now, the thread information for each omp task is taken from blocked ULTs. It works from common task patterns but not for nested task codes that start with single or master clauses (like Fibonacci).
The problem is that we are doubling the thread structures including the task queue so when a new omp task is created it can be done in the real threads queue or in the "fake" one. Then, when we try to join the task... we can not be sure where it is.
However, this issue is related to the OpenMP committee decision about if two omp task can be concurrently executed sharing the thread id
The text was updated successfully, but these errors were encountered: