[svn-r19641] Description:

	Bring r19542:19639 from trunk to revise_chunks branch.

Tested on:
        FreeBSD/32 6.3 (duty) in debug mode
        FreeBSD/64 6.3 (liberty) w/C++ & FORTRAN, in debug mode
        Linux/32 2.6 (jam) w/PGI compilers, w/default API=1.8.x,
                w/C++ & FORTRAN, w/threadsafe, in debug mode
        Linux/64-amd64 2.6 (amani) w/Intel compilers, w/default API=1.6.x,
                w/C++ & FORTRAN, in production mode
        Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
                w/szip filter, w/threadsafe, in production mode
        Linux/PPC 2.6 (heiwa) w/C++ & FORTRAN, w/threadsafe, in debug mode
        Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
                in production mode
        Linux/64-amd64 2.6 (abe) w/parallel, w/FORTRAN, in debug mode
        Mac OS X/32 10.6.4 (amazon) in debug mode
        Mac OS X/32 10.6.4 (amazon) w/C++ & FORTRAN, w/threadsafe,
                in production mode
        Mac OS X/32 10.6.4 (amazon) w/parallel, in debug mode

1 files changed, 74 insertions, 0 deletions

diff --git a/src/H5Ocache.c b/src/H5Ocache.c
index 9e909a6..e64262b 100644
--- a/src/H5Ocache.c
+++ b/src/H5Ocache.c
@@ -560,6 +560,21 @@ done:
  *		koziol@ncsa.uiuc.edu
  *		Mar 20 2003
  *
+ * Changes:     In the parallel case, there is the possibility that the
+ *              the object header may be flushed by different processes
+ *              over the life of the computation.  Thus we must ensure
+ *              that the chunk images are up to date before we mark the
+ *              messages clean -- as otherwise we may overwrite valid
+ *              data with a blank section of a chunk image.
+ *
+ *              To deal with this, I have added code to call
+ *              H5O_chunk_serialize() for all chunks before we
+ *              mark all messages as clean if we are not destroying the
+ *              object.  Do this in the parallel case only, as the problem
+ *              can only occur in this context.
+ *
+ *                                              JRM -- 10/12/10
+ *
  *-------------------------------------------------------------------------
  */
 static herr_t
@@ -573,6 +588,30 @@ H5O_clear(H5F_t *f, H5O_t *oh, hbool_t destroy)
     /* check args */
     HDassert(oh);
 
+#ifdef H5_HAVE_PARALLEL
+    if ( ( oh->cache_info.is_dirty ) && ( ! destroy ) ) {
+
+        size_t i;
+
+        /* scan through all chunks associated with the object header,
+         * and cause them to update their images for all entries currently
+         * marked dirty.  Must do this in the parallel case, as it is possible
+         * that this processor may clear this object header several times
+         * before flushing it -- thus causing undefined sections of the image
+         * to be written to disk overwriting valid data.
+         */
+
+        for ( i = 0; i < oh->nchunks; i++ ) {
+
+            if ( H5O_chunk_serialize(f, oh, i) < 0 ) {
+
+                HGOTO_ERROR(H5E_OHDR, H5E_CANTSERIALIZE, FAIL,
+                            "unable to serialize object header chunk")
+            }
+        }
+    }
+#endif /* H5_HAVE_PARALLEL */
+
     /* Mark messages as clean */
     for(u = 0; u < oh->nmesgs; u++)
         oh->mesg[u].dirty = FALSE;
@@ -830,6 +869,30 @@ done:
  *              koziol@hdfgroup.org
  *              July 12, 2008
  *
+ * Changes:     In the parallel case, there is the possibility that the
+ *              the object header chunk may be flushed by different
+ *              processes over the life of the computation.  Thus we must
+ *              ensure that the chunk image is up to date before we mark its
+ *              messages clean -- as otherwise we may overwrite valid
+ *              data with a blank section of a chunk image.
+ *
+ *              To deal with this, I have added code to call
+ *              H5O_chunk_serialize() for this chunk before we
+ *              mark all messages as clean if we are not destroying the
+ *              chunk.
+ *
+ *              Do this in the parallel case only, as the problem
+ *              can only occur in this context.
+ *
+ *              Note that at present at least, it seems that this fix
+ *              is not necessary, as we don't seem to be able to
+ *              generate a dirty chunk without creating a dirty object
+ *              header.  However, the object header code will be changing
+ *              a lot in the near future, so I'll leave this fix in
+ *              for now, unless Quincey requests otherwise.
+ *
+ *                                              JRM -- 10/12/10
+ *
  *-------------------------------------------------------------------------
  */
 static herr_t
@@ -843,6 +906,17 @@ H5O_cache_chk_clear(H5F_t *f, H5O_chunk_proxy_t *chk_proxy, hbool_t destroy)
     /* check args */
     HDassert(chk_proxy);
 
+#ifdef H5_HAVE_PARALLEL
+    if ( ( chk_proxy->oh->cache_info.is_dirty ) && ( ! destroy ) ) {
+
+        if ( H5O_chunk_serialize(f, chk_proxy->oh, chk_proxy->chunkno) < 0 ) {
+
+            HGOTO_ERROR(H5E_OHDR, H5E_CANTSERIALIZE, FAIL,
+                       "unable to serialize object header chunk")
+        }
+    }
+#endif /* H5_HAVE_PARALLEL */
+
     /* Mark messages in chunk as clean */
     for(u = 0; u < chk_proxy->oh->nmesgs; u++)
         if(chk_proxy->oh->mesg[u].chunkno == chk_proxy->chunkno)