summaryrefslogtreecommitdiffstats
path: root/src/H5A.c
diff options
context:
space:
mode:
authorJohn Mainzer <mainzer@hdfgroup.org>2010-10-17 15:13:24 (GMT)
committerJohn Mainzer <mainzer@hdfgroup.org>2010-10-17 15:13:24 (GMT)
commitf527b1a512ea4b571e22e9efee054d4781afcbc0 (patch)
tree7d68e54480e6012bd4df777baf650a544e32cead /src/H5A.c
parentc002883bcc008a4274433ed8e8275669c09dcfe6 (diff)
downloadhdf5-f527b1a512ea4b571e22e9efee054d4781afcbc0.zip
hdf5-f527b1a512ea4b571e22e9efee054d4781afcbc0.tar.gz
hdf5-f527b1a512ea4b571e22e9efee054d4781afcbc0.tar.bz2
[svn-r19622] Port of fix for the round robin parallel flush bug caused by the failure
of the H5Ocache.c code to update its image of the on disk representation of the object header on a call to the clear callback. This wasn't an issue as long as all flushes of the object header were made from the same process, but if an object header is modified, and then flushed on one process and cleared on the rest, the changes were not be reflected in the images of the on disk representation on all processes where the object header was cleared rather than flushed. If one of these processes did the next flush, the changes were lost in the on disk representation. Fixed this by causing all dirty messages and to be written to the copy of the on disk image maintained by the object header code on both flush and clear. Also added associated test code in t_mdset.c. Also checking in some cache debug code developed while chasing this bug. Commit tested and tested (parallel) on phoenix.
Diffstat (limited to 'src/H5A.c')
0 files changed, 0 insertions, 0 deletions