Hello Konstantina --
I'm Greg Titus with the Chapel core team. I mostly work on the runtime,
with an emphasis on tasking, communication, and memory management.
Sorry for the long delay in responding! We've been busy with the 1.10
release and preparations for SC14 and so on, and I just never did get
back to this. By now you've probably figured all this out yourself, but
just in case not, below are answers to your questions.
The tasking layer primarily supports Chapel tasking constructs (begin,
cobegin, and coforall). We use task lists to help manage the tasks
associated with those tasking constructs. Collecting the tasks for a
construct together is mostly done so that we can run those tasks in a
desirable order with respect to all the other active tasks, given a
potentially limited number of pthreads to host the tasks on. In
particular, it allows the pthread hosting the parent task that
encounters a parallel construct to run all the child tasks resulting
from that construct one after another serially, when all other pthreads
are busy running other tasks and no more pthreads can be created. This
prevents one kind of deadlock due to having more tasks than pthreads to
host them on.
In addition, the tasking layer has a subsidiary role in supporting
on-stmts. We implement on-stmts by having the tasking layer on the
target locale run a synthetic task which (1) calls the on-stmt's body
and then when that returns, (2) sets a flag indicating so back on the
initiating locale. The code that encountered the on-stmt waits for this
flag to be set (so the on-stmt body must have completed) before it
proceeds beyond the on-stmt. The comm layer on the target locale
launches the on-stmt body task by calling the tasking layer function
chpl_task_startMovedTask(). That function is not used for anything other
than launching on-stmt task bodies on target locales. Note that on-stmts
are not actually tasking constructs in the Chapel sense; we just do
things this way because taking advantage of tasking layer capabilities
was the easiest way to accomplish what we needed. Because we have this
ACK-based method for getting the execution ordering right for on-stmts,
we don't use a task list in that case.
Specific answers interspersed below ...
On 9/26/2014 3:07 PM, Panagiotopoulou, Konstantina wrote:
Hello all,
I was looking into the fifo tasking layer and I was wondering
why moved tasks are added to the task pool with chpl_task_list_p = NULL.
In runtime/src/tasks/fifo/tasks-fifo.c, in the function
chpl_task_startMovedTask there is the call:
-- (void) add_to_task_pool(movedTaskWrapper, pmtwd, pmtwd->chpl_data,
NULL); --.
I can't tell if chpl_task_list_p is marked as NULL because a thread
will pick it up
immediately(can we guarantee this by calling schedule_next_task(1)?
and why do that now and not inside the launch_next_task_in_new_thread),
or because there is no tasklist entry for it.
The latter: there is no task list for the synthetic on-stmt body task
launched by chpl_task_startMovedTask(), because there are no other
sibling tasks that need to be managed along with it. We don't care when
that synthetic task actually gets executed. We just trust that
eventually it will. In the meantime, the code that originally
encountered the on-stmt on the initiating locale waits for the on-stmt
completion indicator to be set.
I have the following test program.
cobegin{
on Locales[1] do{
foo1();
cobegin{
foo2();
foo3();
}
}
foo4();
}
Will foo1() be added in the tasklist of locale 0, locale 1 or neither
of them?
Neither, at least not as such. The call to foo1() is just a call, not a
task. It will be executed on the locale corresponding to Locales[1], as
part of the on-stmt body:
{
foo1();
cobegin {
foo2();
foo3();
}
}
A task that calls this body will be sent to the tasking layer on the
target locale by means of a call to chpl_task_startMovedTask(), but it
won't be associated with a task list.
If it's added to any of the tasklists, how can we ensure execution has
started,
since the pointer ltask (in add_to_task_pool call) is NULL?
If it's not added to any tasklist, is it governed by an implicit sync
(of the "on" block or of main()) as with begin_task?
Right, the on-stmt completion indicator is an implicit sync. Though
again, it's important to remember that on-stmts are not actually tasking
constructs, in the sense of creating parallel work. Execution of the
task on the originating locale is suspended while the on-stmt body
executes on the target locale. From the point of view of Chapel
semantics, the place of execution changes from the originating locale to
the target locale and then back again, but the execution is serial
throughout.
I suppose a more general question would be, can locale 0 get any info
on the state of moved tasks?(including foo2() and foo3())
No, it can't. The tasking layer implementations are entirely
locale-local. They don't know anything about what's going on in other
locales.
Finally, what is the purpose of assert(id == chpl_nullTaskID);
since the id is not used anywhere else in the function?
That's just a sanity check. Someday I'd like to make the IDs of tasks
created for Chapel tasking constructs be unique across the entire
program (all locales). Currently they are only unique within the locale.
For program-wide uniqueness to work properly we would need to send the
ID of the task encountering an on-stmt across to the remote task that
executes the on-stmt body on the target locale, so that any reference to
the task ID within the on-stmt body produces the same result as one
would get in the same Chapel task on the locale where the task was
created. This piece of the interface is there to support doing that, but
there's no code to actually achieve the goal. The assert() is there to
make sure that no caller expects support for this capability before the
fifo tasking layer can actually do it.
Thank you for your interest in Chapel, and I promise to answer future
questions in a more timely way!
greg
Thanks in advance.
Konstantina
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
