summaryrefslogtreecommitdiffstats
path: root/perform
diff options
context:
space:
mode:
authorJohn Mainzer <mainzer@hdfgroup.org>2010-11-18 20:56:25 (GMT)
committerJohn Mainzer <mainzer@hdfgroup.org>2010-11-18 20:56:25 (GMT)
commit8ed20b39d6684b59f4c8a7adb46bf2dfb876c9e1 (patch)
treef7ab14717fc0c5145fbe8ce0f7434412e0130015 /perform
parent0bb0aa86e71049ae91234a91822968222b53c6cf (diff)
downloadhdf5-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