[mpich-discuss] MPI-IO and (potentially) unnecessary synchronization

Rob Latham robl at mcs.anl.gov
Sat May 7 13:45:53 CDT 2011


On Thu, Sep 02, 2010 at 02:08:43PM -0500, Rajeev Thakur wrote:
> Burlen,
>             MPI_File_close is defined to be collective. It doesn't need to be synchronizing, but the implementation uses a barrier internally for the following reason given in romio/mpi-io/close.c.
> 
> /* need a barrier because the file containing the shared file
>         pointer is opened with COMM_SELF. We don't want it to be
>         deleted while others are still accessing it. */

I'm reaching way back into the archives for this one.

I think this barrier is unneeded.  Yes, the file is opened with
COMM_SELF but the drivers that support shared file pointers
(ADIO_SHARED_FP) are the posix-compliant ones. 

POSIX semantics specify that deleting a file does not unlink a file.
N processors have it open, it only gets removed after N closes. 

In PVFS land we call this behavior "idiotic" and don't support it, but
neither AD_PVFS nor AD_PVFS2 support shared file pointers :>

==rob

-- 
Rob Latham
Mathematics and Computer Science Division
Argonne National Lab, IL USA


More information about the mpich-discuss mailing list