On Tue, Jun 25, 2019 at 04:55:17AM +0900, 김규래 wrote:
> I'm not very familiar with the gomp plugin system.
> However, looking at 'GOMP_PLUGIN_target_task_completion' seem like tasks have
> to go in and out of the runtime.
> In that case, is it right that the tasks have to know from which queue they
> came from?
> I think I'll have to add the id of the corresponding queue of each task in
> the gomp_task structure.
While libgomp has a plugin system, the only supported plugins are those in
the tree, i.e. libgomp/plugin/plugin-{hsa,nvptx}.c and
liboffloadmic/plugin/*
nvptx plugin doesn't have async support ATM, so it is just hsa and xeonphi
offloading that can call it when an asynchronous target region execution is
over. No matter in which task queue the task is, gomp_target_task_completion
needs to ensure that if something already waits on it (taskwait, taskgroup
end, barrier, dependency wait), that it is awaken.
And, like for other parts of task.c, there needs to be a design what lock
is used to protect any code that needs to be guarded.
The current code as you know uses team->task_lock as a big lock, I think
with the separate workqueues + work stealing you need per implicit task lock
+ the per team (team->task_lock), design the locking such that there is no
ABBA deadlock possibility and that you use the team task lock only when
really necessary (not sure, but perhaps one example where I really don't see
much way to avoid the per team lock are task dependencies, the hash table
for that etc.).
Jakub
