CODEWITHSUNDEEP
multithreadingfortranthread-safety
Matt P
Matt P

Reputation: 2357

Is reading/writing to different elements of a module array thread-safe?

As long as a program does not allow simultaneous writes to the same elements of a shared data structure that is stored in a module, is it thread-safe? I know this is a noob question, but couldn't find it explicitly addressed anywhere. Here's the situation:

At the beginning of a program, data is initialized and stored in a module-level allocatable array (FIELDVARS) which then becomes accessible to any subroutine where the module is referenced by a USE statement.

Suppose now that the program enters a multi-threaded and/or multi-core computational phase, and FIELDVARS is accessed for "read/write" operations during repeated multiple simultaneous calls to subroutine (COMPUTE).

Once the computational phase is complete, the program returns to a single-threaded phase and FIELDVARS must be used in a subsequent subroutine (POST). However, FIELDVARS cannot be added to the input args of COMPUTE or POST because these are called from a closed-source main program. Therefore the module-level array is used to pass the addt'l data between subroutines.

Assume that FIELDVARS and COMPUTE have been designed so that each call to COMPUTE will always give access to a set of unique elements of FIELDVARS, which are guaranteed to be different than for any other call, so that simultaneous "write" operations on the same elements will never occur. For example:

[ 1, 2, 3, 4, 5,  6, 7, 8, 9, 10, ... ]  <-- FIELDVARS
  ^---call 1---^  ^---call 2---^  ...    <-- Each call to COMPUTE is guaranteed to access a specific set of elements of FIELDVARS.

Question: Is this scenario considered "thread-safe", "conditionally safe", or "not thread-safe"? If it is not safe, what is the specific danger and what would you suggest to handle it?

Other relevant details: 

! DEMO MODULE W/ ALLOCATABLE INTEGER ARRAY
module DATA_MODULE
  integer, dimension(:), allocatable :: FIELDVARS  !<-- allocated/populated elsewhere, prior to calling COMPUTE
end module DATA_MODULE


! DEMO COMPUTE SUBROUTINE (THREADED PHASE W/ MULTIPLE SIMULTANEOUS CALLS)
subroutine COMPUTE(x, y, x_idx, y_idx, flag)
  use DATA_MODULE
  logical :: flag
  integer :: x,y,x_idx,y_idx                 !<-- different for every call to COMPUTE
  if (flag == .false.) then                  !<-- read data only
    ...
    x = FIELDVARS(x_idx)
    y = FIELDVARS(y_idx)
    ...
  else if (flag == .true.) then              !<-- write data
    ... 
    FIELDVARS(x_idx) = 0
    FIELDVARS(y_idx) = 0
    ...
  endif
end subroutine COMPUTE

Upvotes: 2

Views: 213

Answers (1)

Vladimir F Героям слава
Vladimir F Героям слава

Reputation: 60078

It is fine and many programs depend on that fact. In OpenMP you often loop over arrays and different threads may easily work with elements which are close to each other in memory, especially on the boundaries of the blocks assigned to each thread.

At modern CPUs this is a non-issue. See also https://en.wikipedia.org/wiki/Cache_coherence

What is a real problem is False sharing. Two or more threads working with elements of memory belonging to the same chache line will be compiting for a shared resource and it may be very slow.

Upvotes: 3

Related Questions