3.11.1. Memory locking for guard zones¶
When omp_lock%tasks
is set, external read access to task memory is locked
while the task%update is actively modifying the task memory (this occupies only
a small fraction of the time to do task%update
), so the procedure is fully
thread-safe. One can optimize this, at the cost of an extremely small chance
to get relatively bad guard cell values on occasion:
When download_link wants to access a source task, it would do::
!-----------------------------------------------------------------------------
! Acquire the task in locked mode, so nothing can change while we decide
! whether to keep it. While we have the lock, we get the slot indices ``jt``
! and weights ``pt`` -- these are not going to change if we release the lock,
! and the source task updates -- unless it updates several times and those
! slots are overwritten with newer time values.
!-----------------------------------------------------------------------------
call source%lock%set ('guard cells')
call source%time_slots (target%time, jt, pt)
!-----------------------------------------------------------------------------
! If the target%time is in the first available time slot,
! which is source%t(source%iit(1:2)), that first slot could possibly be
! overwritten, in some very unusual cases, when the source task is just about
! to switch in that slot as "new", and if the current task by chance is delayed
! enough. In that case, keep the lock until after guard zones are loaded.
!-----------------------------------------------------------------------------
if (target%time < source%t(source%iit(2))) then
call target%get_guard_zones_from (source, jt, pt)
call source%lock%unset ('guard cells')
else
call source%lock%unset ('guard cells')
call target%get_guard_zones_from (source, jt, pt)
end if
Note that the get_guard_cells from (source)
procedure must rely on only
the source%it information, and