On Fri, Jan 2, 2026 at 10:42 PM Thomas Koenig <[email protected]> wrote: > > Am 02.01.26 um 20:52 schrieb Harald Anlauf: > > Well, it is certainly *not advisable* to write to the same unit. > > > > One way to avoid the race condition is to use sth. like > > > > !$OMP CRITICAL > > WRITE(*,*) X > > !$OMP END CRITICAL > > > > But is it really required? > > The closest equivalent in pure Fortran is DO CONCURRENT. There, one only > finds > > 11.1.7.5 Additional semantics for DO CONCURRENT constructs > > [...] > > 8 A DO CONCURRENT construct shall not contain an input/output statement > that has an ADVANCE= specifier. > > so the rest is permitted. > > Hmm... after reading that, I changed my mind. I now think that I/O > should also be allowed within OMP PARALLEL.
Hello, long time no see. The OpenMP spec AFAIU has no special treatment of procedures that do I/O. If a procedure is thread-unsafe, it's up to the user to use some appropriate synchronization construct like the OMP CRITICAL section that Harald mentions above. That being said, I'd say it would be a pretty bad QoI issue if the GFortran runtime library would not be thread-safe (heck, there's even a section in the manual about it at https://gcc.gnu.org/onlinedocs/gfortran/Thread-safety-of-the-runtime-library.html ). And indeed thread-safety is the reason why there is all the locking around I/O in libgfortran. Ripping that out and telling users to handle synchronization themselves would, I think, be considered a pretty bad regression. For the particular case of I/O to the same unit, yes the libgfortran I/O locking will prevent concurrent I/O to the same unit. So putting some OMP PARALLEL constructs around a loop that does nothing else than I/O to the same unit will go no faster than doing it sequentially. But that's still better than having the concurrent I/O unsynchronized which would likely corrupt the internal state in the library, as well as resulting in a file with jumbled contents. -- Janne Blomqvist
