diff options
Diffstat (limited to 'src/H5ACpkg.h')
| -rw-r--r-- | src/H5ACpkg.h | 110 |
1 files changed, 55 insertions, 55 deletions
diff --git a/src/H5ACpkg.h b/src/H5ACpkg.h index e31f245..fc51ef0 100644 --- a/src/H5ACpkg.h +++ b/src/H5ACpkg.h @@ -21,7 +21,7 @@ * Source files outside the H5AC package should include * H5ACprivate.h instead. * - * The one exception to this rule is testpar/t_cache.c. The + * The one exception to this rule is testpar/t_cache.c. The * test code is easier to write if it can look at H5AC_aux_t. * Indeed, this is the main reason why this file was created. */ @@ -51,9 +51,9 @@ #define H5AC_DEBUG_DIRTY_BYTES_CREATION 0 /*------------------------------------------------------------------------- - * It is a bit difficult to set ranges of allowable values on the - * dirty_bytes_threshold field of H5AC_aux_t. The following are - * probably broader than they should be. + * It is a bit difficult to set ranges of allowable values on the + * dirty_bytes_threshold field of H5AC_aux_t. The following are + * probably broader than they should be. *------------------------------------------------------------------------- */ @@ -71,71 +71,71 @@ * are some features of the metadata cache that are specific to it, and which * therefore do not belong in the more generic H5C cache code. * - * In particular, there is the matter of synchronizing writes from the + * In particular, there is the matter of synchronizing writes from the * metadata cache to disk in the PHDF5 case. * - * Prior to this update, the presumption was that all metadata caches would - * write the same data at the same time since all operations modifying - * metadata must be performed collectively. Given this assumption, it was - * safe to allow only the writes from process 0 to actually make it to disk, + * Prior to this update, the presumption was that all metadata caches would + * write the same data at the same time since all operations modifying + * metadata must be performed collectively. Given this assumption, it was + * safe to allow only the writes from process 0 to actually make it to disk, * while metadata writes from all other processes were discarded. * - * Unfortunately, this presumption is in error as operations that read - * metadata need not be collective, but can change the location of dirty - * entries in the metadata cache LRU lists. This can result in the same - * metadata write operation triggering writes from the metadata caches on - * some processes, but not all (causing a hang), or in different sets of - * entries being written from different caches (potentially resulting in + * Unfortunately, this presumption is in error as operations that read + * metadata need not be collective, but can change the location of dirty + * entries in the metadata cache LRU lists. This can result in the same + * metadata write operation triggering writes from the metadata caches on + * some processes, but not all (causing a hang), or in different sets of + * entries being written from different caches (potentially resulting in * metadata corruption in the file). * * To deal with this issue, I decided to apply a paradigm shift to the way * metadata is written to disk. * - * With this set of changes, only the metadata cache on process 0 is able - * to write metadata to disk, although metadata caches on all other + * With this set of changes, only the metadata cache on process 0 is able + * to write metadata to disk, although metadata caches on all other * processes can read metadata from disk as before. * * To keep all the other caches from getting plugged up with dirty metadata, * process 0 periodically broadcasts a list of entries that it has flushed * since that last notice, and which are currently clean. The other caches - * mark these entries as clean as well, which allows them to evict the + * mark these entries as clean as well, which allows them to evict the * entries as needed. * * One obvious problem in this approach is synchronizing the broadcasts - * and receptions, as different caches may see different amounts of - * activity. + * and receptions, as different caches may see different amounts of + * activity. * - * The current solution is for the caches to track the number of bytes - * of newly generated dirty metadata, and to broadcast and receive + * The current solution is for the caches to track the number of bytes + * of newly generated dirty metadata, and to broadcast and receive * whenever this value exceeds some user specified threshold. * * Maintaining this count is easy for all processes not on process 0 -- - * all that is necessary is to add the size of the entry to the total + * all that is necessary is to add the size of the entry to the total * whenever there is an insertion, a rename of a previously clean entry, * or whever a previously clean entry is marked dirty in an unprotect. * * On process 0, we have to be careful not to count dirty bytes twice. - * If an entry is marked dirty, flushed, and marked dirty again, all - * within a single reporting period, it only th first marking should - * be added to the dirty bytes generated tally, as that is all that + * If an entry is marked dirty, flushed, and marked dirty again, all + * within a single reporting period, it only th first marking should + * be added to the dirty bytes generated tally, as that is all that * the other processes will see. * * At present, this structure exists to maintain the fields needed to * implement the above scheme, and thus is only used in the parallel * case. However, other uses may arise in the future. * - * Instance of this structure are associated with metadata caches via - * the aux_ptr field of H5C_t (see H5Cpkg.h). The H5AC code is + * Instance of this structure are associated with metadata caches via + * the aux_ptr field of H5C_t (see H5Cpkg.h). The H5AC code is * responsible for allocating, maintaining, and discarding instances - * of H5AC_aux_t. + * of H5AC_aux_t. * * The remainder of this header comments documents the individual fields * of the structure. * * JRM - 6/27/05 * - * magic: Unsigned 32 bit integer always set to - * H5AC__H5AC_AUX_T_MAGIC. This field is used to validate + * magic: Unsigned 32 bit integer always set to + * H5AC__H5AC_AUX_T_MAGIC. This field is used to validate * pointers to instances of H5AC_aux_t. * * mpi_comm: MPI communicator associated with the file for which the @@ -146,14 +146,14 @@ * mpi_size: Number of processes in mpi_comm. * * write_permitted: Boolean flag used to control whether the cache - * is permitted to write to file. + * is permitted to write to file. * - * dirty_bytes_threshold: Integer field containing the dirty bytes - * generation threashold. Whenever dirty byte creation - * exceeds this value, the metadata cache on process 0 + * dirty_bytes_threshold: Integer field containing the dirty bytes + * generation threashold. Whenever dirty byte creation + * exceeds this value, the metadata cache on process 0 * broadcasts a list of the entries it has flushed since * the last broadcast (or since the beginning of execution) - * and which are currently clean (if they are still in the + * and which are currently clean (if they are still in the * cache) * * Similarly, metadata caches on processes other than process @@ -161,16 +161,16 @@ * the threshold is exceeded. * * dirty_bytes: Integer field containing the number of bytes of dirty - * metadata generated since the beginning of the computation, - * or (more typically) since the last clean entries list + * metadata generated since the beginning of the computation, + * or (more typically) since the last clean entries list * broadcast. This field is reset to zero after each such * broadcast. * - * dirty_bytes_propagations: This field only exists when the + * dirty_bytes_propagations: This field only exists when the * H5AC_DEBUG_DIRTY_BYTES_CREATION #define is TRUE. * * It is used to track the number of times the cleaned list - * has been propagated from process 0 to the other + * has been propagated from process 0 to the other * processes. * * unprotect_dirty_bytes: This field only exists when the @@ -184,7 +184,7 @@ * H5AC_DEBUG_DIRTY_BYTES_CREATION #define is TRUE. * * It is used to track the number of times dirty bytes have - * been created via unprotect operations since the last time + * been created via unprotect operations since the last time * the cleaned list was propagated. * * insert_dirty_bytes: This field only exists when the @@ -198,7 +198,7 @@ * H5AC_DEBUG_DIRTY_BYTES_CREATION #define is TRUE. * * It is used to track the number of times dirty bytes have - * been created via insert operations since the last time + * been created via insert operations since the last time * the cleaned list was propagated. * * rename_dirty_bytes: This field only exists when the @@ -212,7 +212,7 @@ * H5AC_DEBUG_DIRTY_BYTES_CREATION #define is TRUE. * * It is used to track the number of times dirty bytes have - * been created via rename operations since the last time + * been created via rename operations since the last time * the cleaned list was propagated. * * d_slist_ptr: Pointer to an instance of H5SL_t used to maintain a list @@ -231,36 +231,36 @@ * 2) a previously clean entry is renamed, and it does not * already appear in the dirty entry list, or * - * 3) a previously clean entry is unprotected with the - * dirtied flag set and the entry does not already appear + * 3) a previously clean entry is unprotected with the + * dirtied flag set and the entry does not already appear * in the dirty entry list. * * Entries are added to the dirty entry list whever they cause - * the dirty bytes count to be increased. They are removed + * the dirty bytes count to be increased. They are removed * when they appear in a clean entries broadcast. Note that * renames must be reflected in the dirty entry list. * - * To reitterate, this field is only used on process 0 -- it + * To reitterate, this field is only used on process 0 -- it * should be NULL on all other processes. * - * d_slist_len: Integer field containing the number of entries in the - * dirty entry list. This field should always contain the + * d_slist_len: Integer field containing the number of entries in the + * dirty entry list. This field should always contain the * value 0 on all processes other than process 0. It exists * primarily for sanity checking. * - * c_slist_ptr: Pointer to an instance of H5SL_t used to maintain a list + * c_slist_ptr: Pointer to an instance of H5SL_t used to maintain a list * of entries that were dirty, have been flushed * to disk since the last clean entries broadcast, and are * still clean. Since only process 0 can write to disk, this * list only exists on process 0. * * In essence, this slist is used to assemble the contents of - * the next clean entries broadcast. The list emptied after + * the next clean entries broadcast. The list emptied after * each broadcast. - * + * * c_slist_len: Integer field containing the number of entries in the clean - * entries list (*c_slist_ptr). This field should always - * contain the value 0 on all processes other than process 0. + * entries list (*c_slist_ptr). This field should always + * contain the value 0 on all processes other than process 0. * It exists primarily for sanity checking. * * write_done: In the parallel test bed, it is necessary to ensure that @@ -297,7 +297,7 @@ typedef struct H5AC_aux_t int32_t dirty_bytes; -#if H5AC_DEBUG_DIRTY_BYTES_CREATION +#if H5AC_DEBUG_DIRTY_BYTES_CREATION int32_t dirty_bytes_propagations; |