1. 12 Jan, 2015 2 commits
  2. 08 Jan, 2015 2 commits
  3. 07 Jan, 2015 2 commits
  4. 06 Jan, 2015 1 commit
    • Kenneth Raffenetti's avatar
      Fortran profiling interface fix · 6ce38c27
      Kenneth Raffenetti authored
      Previous re-organization of the library symbols resulted in a
      situation where Fortran programs could no longer be profiled using
      tools written in C. Functions in libmpifort directly called the
      PMPI_* versions in libmpi.
      Now we always call the MPI_* versions from libmpifort. In the case
      where we are building a separate profiling library, we use a new
      preprocessor flag to ensure we call PMPI_* from inside libpmpi.
      Additional bug fix:
        - always define mpi_conversion_fn_null_, there is no pmpi version
      Fixes #2209
      Signed-off-by: default avatarJunchao Zhang <jczhang@mcs.anl.gov>
  5. 05 Jan, 2015 6 commits
  6. 04 Jan, 2015 2 commits
  7. 19 Dec, 2014 1 commit
    • Paul Coffman's avatar
      barrier in close whenever shared files supported · ef1cf141
      Paul Coffman authored and Rob Latham's avatar Rob Latham committed
      Currently in the MPI_File_close there is a barrier in place whenever the
      ADIO_SHARED_FP feature is enabled AND the ADIO_UNLINK_AFTER_CLOSE
      feature is disabled right before the code to close the shared file
      pointer and potentially unlink the shared file itself.  PE testing on
      GPFS revealed a situation using the non-collective
      where based on this implementation all tasks needed to wait for all
      other tasks to complete processing before unlinking the shared file
      pointer or the open of the shared file pointer could fail.  This
      situation is illustrated as follows with the simplest example of 2 tasks
      that do this:
      So both tasks call MPI_File_Read_shared at the same time which first
      does the ADIO_Get_shared_fp which does the file open with create mode on
      the shared file pointer.   Only 1 task can actually create the file, so
      there is a race to see who can get it done first.  If task 0 gets it
      created then he is the winner and goes on to use it, read the file and
      then MPI_File_close which then unlinks the shared file pointer first and
      then closes the output file.  Meanwhile, task 1 lost the race to create
      the file and is in error, the error handling in gpfs goes into effect
      and task 1 now just tries to open the file that task 0 created.  The
      problem is this error handling took longer that task 0 took to read and
      close the output file, so at the time when task 0 does the close he is
      the only process with a link since task 1 is still in the create file
      error handlilng code so therefore gpfs goes ahead and deletes the shared
      file pointer.  Then when the error handling code for task 1 does
      complete and he tries to do the open, the file is no longer there, so
      the open fails as does the subsequent read of the shared file pointer.
      Currently GPFS has the ADIO_UNLINK_AFTER_CLOSE  feature enabled, so the
      fix for this is to remove the additional condition of
      ADIO_UNLINK_AFTER_CLOSE  being disabled for the barrier in the close to
      be done.  Presumably this could be an issue for any parallel file system
      so this change is being done in the common code.
      See ticket #2214
      Signed-off-by: default avatarPaul Coffman <pkcoff@us.ibm.com>
      Signed-off-by: Rob Latham's avatarRob Latham <robl@mcs.anl.gov>
  8. 18 Dec, 2014 1 commit
  9. 17 Dec, 2014 2 commits
  10. 16 Dec, 2014 21 commits