DISPATCH
dispatcher4_mod Module Reference

Execute a task list. Since only the master thread is calling check_mpi(), we need to make sure that it handles all send/recv, hence send_priv=.false. and recv_priv=.false., and we can use the simplest receive mechanism (recv_active =.true.), with no buffering needed (queue_unpack=.false.). These values are imposed after the input namelists are read, to make sure the choices are correct. More...

Data Types

type  dispatcher4_t
 

Variables

type(global_taverage_density
 
type(dispatcher4_t), public dispatcher4
 

Detailed Description

Execute a task list. Since only the master thread is calling check_mpi(), we need to make sure that it handles all send/recv, hence send_priv=.false. and recv_priv=.false., and we can use the simplest receive mechanism (recv_active =.true.), with no buffering needed (queue_unpack=.false.). These values are imposed after the input namelists are read, to make sure the choices are correct.

Strategy: Keep track of, separately, the number of ready tasks, the number of currently spawned tasks, and the number of currently busy tasks. To this end, define the following states:

state=0: task is inactive or new state=1: the task is ready to update, but not yet spawned state=2: the task has been spawned state=3: the task is busy updating state=4: the task has finished updating

The simplest strategy for counting is to keep track of the number of tasks in each state, by incrementing the count for the new state and decrementing the count for the old state, whenever the state changes. These counts should be part of the dispatcher data type.

On the balance between spawning tasks for other treads and actually working on an update: If a process has N threads, and has N tasks active, evenly spread in their progress, then essentially all of these tasks will have finished updating while the master thread works on its update. Hence there must be approximately N additional tasks spawned, but not yet busy updating. Hence, the criterion for the master thread to take on work itself is that there are at least N tasks in state 2 (not counting those in state 3 or 4).

If the master thread is unable to find enough tasks in state 1 for it to be able to reach N in state 2, then it is certainly not a good idea to take on one of the tasks, since there is already a surplus of threads available.

If, on the other hand, there is only single task available in state 2, then it IS a good idea to let the master thread update it, since it then has some useful work to do, while other tasks are finishing, so when the master thread looks at the situation again, there are likely to be a number of new tasks ready to be updated.