Bug 25830 - [libgfortran] Optionally support multi-process locking
[libgfortran] Optionally support multi-process locking
Status: NEW
Product: gcc
Classification: Unclassified
Component: libfortran
4.2.0
: P3 enhancement
: ---
Assigned To: Not yet assigned to anyone
:
Depends on: 25561
Blocks: 18918
  Show dependency treegraph
 
Reported: 2006-01-17 22:06 UTC by Janne Blomqvist
Modified: 2011-04-25 16:41 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-01-17 23:33:50


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janne Blomqvist 2006-01-17 22:06:51 UTC
Currently the gfortran IO library is supposed to be thread safe. Additionally, allowing multiple processes to access the same file could be useful, and if we eventually want to support co-arrays with multiple processes, it will be needed as co-arrays specify that multiple images can access a single file.

On POSIX this can be accomplished with the fcntl() syscall. We'd certainly want to make this optional (perhaps with a compiler command-line switch like the fpe options), to avoid the fcntl() overhead as well as frequent buffer flushing in normal single-process usage.
Comment 1 Janne Blomqvist 2006-01-17 22:07:33 UTC
Change severity to enhancement.
Comment 2 Andrew Pinski 2006-01-17 23:33:50 UTC
Coonfirmed.
Comment 3 Tobias Burnus 2008-11-20 15:52:16 UTC
Other compilers have the SHARE= specifier for OPEN and INQUIRE, e.g. Intel or HP. I'm not sure it is needed, but one could consider supporting it as well when implementing this option.

http://www.intel.com/software/products/compilers/docs/flin/main_for/lref_for/source_files/rflioop.htm

I think Fortran 2008 does not allow to such access which makes it a non-issue in terms of the standard, including for coarrays, but still this is a not so rarely requested feature. (But one has to be careful as a user otherwise the program might read/write garbage.)
Comment 4 Janne Blomqvist 2011-04-25 16:41:26 UTC
Some writings arguing that POSIX locking is more or less fundamentally broken:

http://0pointer.de/blog/projects/locking.html

http://0pointer.de/blog/projects/locking2.html

http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html

AFAICS, if gfortran is to eventually support multi-image IO in the context of Co-array Fortran as in the TR

http://j3-fortran.org/doc/meeting/192/10-166.pdf ,

it is possible to implement all of this without relying on POSIX locking (fcntl) for synchronization, instead using the existing IPC channels that co-arrays provide. 

That being said, it might be necessary to do a fcntl lock+unlock at appropriate places in order to force the NFS client to flush dirty bytes to the server; alternatives to using fcntl() to force NFS flushing is fsync or a close+reopen of the POSIX file descriptor. Close+reopen does have the nice property of being portable and not relying on a working NFS locking implementation.

FWIW, one strange thing about the 10-166 TR is that there is no mention of stream access, which AFAICS is suited to parallel access just like direct access.