3.1.11. Handling bits%init_nbors
¶
When a thread updating a boundary task discovers a bits%init_nbors
,
it should not clear that bit until after the send_to_vnbors()
call,
since the bit needs to be propagated to virtual copies of the task.
The nbor list should not be updated too early, since the thread is updating the
task because it was deemed ready to update based on the existing nbor list,
which has then been used (before the call to task%update()
) to load data
into the guard zones. The existing nbor list might also be used for some
unspecified reason as part of the update, so it should not be touched until
after the task has updated.
Hence the init_nbors()
call should be done by task_list_t%update()
,
after its call to task%update()
, and before the call to
send_to_vnbors()
.
The call to send_to_vnbors()
is immediately preceeded by a
call to load_balance()
, which means the boundary task that will have
a new nbor list generated could possibly be reassigned to another rank.
It will, in any case, since it arrives with bits%init_nbors
set, have
a new nbor list generated also on the other rank, so the result will in
any case be that both the first rank and the other rank will have consistent
nbor lists for the task.
The state of that task after the task%update()
and init_nbors()
is that
of a “dormant” task, ready to be checked as a candidate for the ready queue by
any thread updating one of its (possibly new) nbors. That is at it should be.