https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|1                           |0
             Status|WAITING                     |UNCONFIRMED

--- Comment #13 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> What does the OpenMP standard say about I/O in partallel exexution?

I think OpenMP does not really say anything and leaves it to the base language.
I/O in gfortran is thread safe and Fortran covers parallel I/O in the section
about do concurrent as [quoting Fortran 2023]:

> A DO CONCURRENT construct shall not contain an input/output statement
> that has an ADVANCE= specifier.
> If data are written to a file record or position in one iteration,
> that record or position in that file shall not be read from or written
> to in a different iteration. If records are written to a file connected
> for sequential access by more than one iteration, the ordering of
> records written by different iterations is processor dependent

I think it can be assumed that the same applies to concurrent writes when using
OpenMP as means for implementing parallelization/concurrency.

* * *

>From the discussion in PR 113005, the issue seems to be less/not related not
concurrency itself but more to the number of open file handles, file names etc.
- but maybe there are still concurrency/locking issues. In any case:

PR 113005 comment 15 states that on one system, rwlock_1.f90 produced 25984 (!)
's.*' files.

One issue was fixed by the patch in PR 113005 comment 13 (not committed): "when
thread number greater than 1000, the file_name = 1000_tst.dat, character(11)
will overflow. This will generate the same file_name like ***_tst.dat."

In one case, the issue appears with NFS but not with local disc space - while
another one observes it for tmpfs.

PR 113005 comment 18 shows some lock-order-inversion issues when run under the
sanitizer - which might be false positives.
[The last time I fixed I/O race issues was for PR99529 and PR100352 four years
ago. Thus, there might be still races lurking somewhere.]

Reply via email to