diff options
author | John Mainzer <mainzer@hdfgroup.org> | 2010-11-18 20:56:25 (GMT) |
---|---|---|
committer | John Mainzer <mainzer@hdfgroup.org> | 2010-11-18 20:56:25 (GMT) |
commit | 8ed20b39d6684b59f4c8a7adb46bf2dfb876c9e1 (patch) | |
tree | f7ab14717fc0c5145fbe8ce0f7434412e0130015 /perform | |
parent | 0bb0aa86e71049ae91234a91822968222b53c6cf (diff) | |
download | hdf5-8ed20b39d6684b59f4c8a7adb46bf2dfb876c9e1.zip hdf5-8ed20b39d6684b59f4c8a7adb46bf2dfb876c9e1.tar.gz hdf5-8ed20b39d6684b59f4c8a7adb46bf2dfb876c9e1.tar.bz2 |
[svn-r19825]
Checked in fix for failure in shape same tests that appeared after
Quincy's recent massage of the test code. The problem was a race
condition created when Quincey re-worked the code selecting either
collective or independant I/O.
Previously, when independant I/O was selected in the test, I had
used H5Pset_dxpl_mpio() and H5Pset_dxpl_mpio_collective_opt() to
select collective semantics with independant I/O going on under
the hood. Quincey modified this to call H5Pset_dxpl_mpio() when
collective I/O was selected, and do nothing in the independant I/O
case. As a result, processes were able to race ahead and
modify the initial values of the data set before some processes
had verified that the initialization was correct.
Solved the problem by adding barriers, and making all barriers
dependant on independant I/O being selected.
Tested parallel on amani and phoenix. h5committested.
Note that parallel on amani and h5committest on heiwa failed
several times before I got a clean pass without code changes.
The failures on amani seemed to be time outs caused by contention
for the machine -- worryingly, they occurred in the shape same
tests. However, given subsequent passes and passes on jam and
phoenix, I am going ahead with the commit.
The failure on heiwa was in the fheap test. I don't see how
this can be related to changes in testpar, and in any case, it
went away on the second try.
Diffstat (limited to 'perform')
0 files changed, 0 insertions, 0 deletions