On 10/04/2015 10:26 AM, Aldy Hernandez wrote:
However magically this happened before :), my attached changes to gomp_task_run_pre() will move this task to the end of the queue such that the WAITING tasks are first.
FWIW, thinking about this some more, I suppose setting a task to GOMP_TASK_TIED by iterating through its sibling queue could render the taskgroup queue into an indeterminate state, by leaving the taskgroup with TIED tasks before WAITING tasks. And vice versa, removing from taskgroup could leave the sibling queue confused.
However... since we remove the child_task from the team->task_queue altogether in gomp_task_run_pre(), the team->task_queue will still be sane and barrier picking should work. I suppose what's happening is that if we mess up the child or taskgroup queues, barrier picking will still pick stuff up. ??
Also, sibling and taskgroup queues are created by inserting things at the top, while the team's task_queue is populated by inserting at the end. So barrier and child/taskgroup picking are working in opposite orders.
...or some combination of the above. Either way, I say we've been lucky. I still think we should fix those links as per my patch.
Aldy
