Work at enqueue for tasks (aimed at communication)
So from discussions I had at the IXPUG meeting, one issue that people discussed with me was how they couldn't get MPI to work how they would like in whatever task implementation they were using.
I think extending quicksched's model to support a function call at enqueue (specified by the user, things such as MPI_Isend for example) might let us test this out and say we want this in whatever the task standard ends up being. Also a custom trylock function specific to task type.
Something like
qsched_add_enqueue_function( function_pointer);
qsched_add_lock_function( function_pointer, int task_type);
to be called by the user, and enabled or disabled at library compilation time (we could start our own sequence of difficult to remember defines, such as other major libraries...), but something like ./configure --with-enqueue-funcs . Would be restricted to 1 function for all tasks and would be similar to the function provided to qsched_run
.
I don't think we need a dequeue
function or unlock
function at this time. This lets people do communication as follows, for e.g. a send task:
qsched_addtask(..., task_type_send, ...)
qsched_add_enqueue_function(&enqueue_func)
qsched_add_lock_function( &send_lock_func, task_type_send);
...
void enqueue_func(int type, int *data)
{
if(type == task_type_send)
{
MPI_ISend(...);
}
}
...
int send_lock_func(int *data)
{
return MPI_Test(...);
}
Thoughts @nnrw56 @matthieu - this should be sufficient for a front-end specification? The back end for the custom lock functions may be a bit complex and it all adds more overhead that for a basic shared memory computation is unwanted, so I think off-by-default is necessary.