Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Thread safe Fortran

Ida_Norderhaug_D_
246 Views

I'm working on making an existing fortran library thread safe. I do this by setting copiler options: /recursive, /reentrancy:threaded, /threads and /Qauto, and by not writing to global variables. I am also in the process of removing data-initialized variables, as these seem to implicitly declared as SAVE. Anything else I need to think about?

0 Kudos
3 Replies
jimdempseyatthecove
Black Belt
246 Views

If your library routines call other (3rd party) library routines, those routines must be thread safe as well.

When your library routines modify caller's data you must either specify concurrency requirements (don't do this...) or specific ATOMIC or CRITICAL sections.

When using CRITICAL sections, use named CRITICAL sections (I usually set the name to that of the subroutine/function).

Be aware that some runtime library routines have critical sections. This may cause performance issues, and therefore you may wish to use different routines (or write your own).

You may find that some routines have "do once" code to initialize data. If this initialized data is dependent on external factors (e.g. date, random number generator state, etc...), .AND. if your library is shared, then this initialized data (and do once flag) needs to be located in the calling process exclusive address space and not in the shared address space of your library.

Be careful of thread local storage variables within your library as different compiler vendors (and O/S's) may handle these differently (passing in by reference or value is no problem).

Jim Dempsey

Ida_Norderhaug_D_
246 Views

jimdempseyatthecove wrote:

When your library routines modify caller's data you must either specify concurrency requirements (don't do this...) or specific ATOMIC or CRITICAL sections.

Is it a problem to modify the callers data if this data is private to the thread calling the routine?

jimdempseyatthecove
Black Belt
246 Views

No.

When the user application calling your library is single threaded, or when caller application is multi-threaded...
.AND. your library is multi-threaded (this may necessitate nested parallelism), then the issues of concurrent access lies solely within your library.

However, on the other hand, when the caller(s) is(are) multi-threaded, regardless as to if your library uses nested parallelism, it is the caller's responsibility to assure no race conditions exist (multiple threads potentially concurrently modifying same data).

Additionally, you can provide a library routine, that (either by option or all the time), thread-safely handles the boundary variable that potentially have concurrent accesses. An example of this is the boundary cells of a tile, where each tile is concurrently processed by different caller's threads, and where the computation modifies cell data just outside the tile boundary.

Jim Dempsey

Reply