Internal WRITE appears not thread safe

Internal WRITE appears not thread safe

I have a routine that is called within a parallel loop. Among others, it is doing an internal WRITE to a string that is thread private.

Anyway this WRITE is causing program crashes ("double free or corruption") when running with multiple threads. So I must assume that WRITE is not thread safe, which is to be expected for file I/O but not for internal WRITE's. Can anybody confirm or comment ? Compiler version is 11.1.056.

 

publicaciones de 12 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

I suppose you might try an omp single around the internal write to verify this.  The internal write would use hidden buffers which are likely not to be thread aware. 

My textbook says omp workshare is intended for parallelization of f90 array assignments.  Conceptually, it seems that this could be extended to internal write, but even the simpler cases are usually implemented by ifort with omp single.

If a similar case using the -parallel option instead of -openmp results in the compiler saying it can't be parallelized, that would be further indication of the lack of parallel capability for internal write.

It would be comforting to hear from the compiler team's OpenMP standards member to confirm if internal WRITEs are or are not thread safe.

IMHO, internal WRITE ought to be thread safe .AND. implimented without critical section. Doing so will permit multiple threads to format output to seperate buffers, and then have yet additional thread perform the file WRITE (as single text line per pre-formatted text). Using "!omp atomic write" in the case of internal write should not be necessary. Please confirm as to if it is or is not. If it is, then this may necessitate calling a C function to perform the formatting.

Jim Dempsey

www.quickthreadprogramming.com

Please try this with a current version - and be sure to build with -threads.

Steve - Intel Developer Support

Thanks to everybody who responded. Here is what I did:

Test 1: Replaced the WRITE with a dummy assignment and the problem is gone. That's a pretty clear indication.

Test 2: As I can't easily rebuild all with a newer compiler I did that only for the routine in question and for the linking. The good news: The .mod files are compatible from 11.1 to 13.2 and so are the runtime libs. The bad news: The original problem is still there. 

As I really dislike CRITICAL I consider making my own itoa() function in Fortran (need only 2 digits). Calling sprintf() may be quite tricky.

Michael

In user32 (Windows version) is function wvsprintf. It will be your responsibility to assure null terminated format string (as well as null terminated string arguments).

I know this is a Linux forum, so.... use the wvxprintf function interface from user32 and modify it for use with your Linux equivilent C runtime function.

Jim Dempsey

www.quickthreadprogramming.com

We believe Internal WRITE to be thread-safe when the correct libraries are used. We'd appreciate a test program that shows otherwise.

Steve - Intel Developer Support

Trying to construct a reproducer it turned out that the symptom was caused by upper level routines that were not compiled with -openmp and thus caused malloc / free corruption. It has nothing to do with the WRITE. After fixing the (rather complex) Makefiles the routine in question now runs fine in parallel so the internal WRITE indeed behaves thread safe. I have to apologize for the confusion.

Michael

The usual advice is to declare procedures as RECURSIVE if you want thread safety regardless of compile options.  Setting -openmp everywhere in a build using OpenMP is a satisfactory method.

>>The usual advice is to declare procedures as RECURSIVE if you want thread safety regardless of compile options. 

Except in this case it was a link/runtime library issue (single thread malloc/free)

Jim Dempsey

www.quickthreadprogramming.com

I suppose it shouldn't be possible to get a non thread-safe malloc with a correctly constructed link command.  I guess Steve's comment about linking the wrong libraries points to that possibility.  The Intel compiler option -openmp clearly must set up a link command for thread safety.

The link was with -openmp but not all of the compiles were, so some routines were not compiled for reentrancy. That was my fault. Don't waste more time with this. And thanks again !

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya