diff options
Diffstat (limited to 'src/H5C.c')
-rw-r--r-- | src/H5C.c | 18 |
1 files changed, 9 insertions, 9 deletions
@@ -771,7 +771,7 @@ H5C_prep_for_file_close(H5F_t *f) * * 2) Since the FSM settle routines are only invoked once during * file close, invoking them now will prevent their invocation - * during a flush, and thus avoid any resulting entrie dirties, + * during a flush, and thus avoid any resulting entry dirties, * deletions, insertion, or moves during the flush. */ if (H5C__serialize_cache(f) < 0) @@ -2564,7 +2564,7 @@ H5C_protect(H5F_t *f, const H5C_class_t *type, haddr_t addr, void *udata, unsign * * Also, if the min_clean_size requirement is not met, we * should also call H5C__make_space_in_cache() to bring us - * into complience. + * into compliance. */ if (cache_ptr->index_size >= cache_ptr->max_cache_size) @@ -4861,7 +4861,7 @@ H5C__autoadjust__ageout__evict_aged_out_entries(H5F_t *f, hbool_t write_permitte /* for now at least, don't bother to maintain the minimum clean size, * as the cache should now be less than its maximum size. Due to - * the vaguries of the cache size reduction algorthim, we may not + * the vaguries of the cache size reduction algorithm, we may not * reduce the size of the cache. * * If we do, we will calculate a new minimum clean size, which will @@ -5873,7 +5873,7 @@ H5C__flush_invalidate_ring(H5F_t *f, H5C_ring_t ring, unsigned flags) * If either of these happen, and one of the target * or proxy entries happens to be the next entry in * the hash bucket, we could either find ourselves - * either scanning a non-existant entry, scanning + * either scanning a non-existent entry, scanning * through a different bucket, or skipping an entry. * * Neither of these are good, so restart the @@ -8086,7 +8086,7 @@ done: * To cork the object * Return error if the object is already corked * H5C__UNCORK: - * To uncork the obejct + * To uncork the object * Return error if the object is not corked * H5C__GET_CORKED: * To retrieve the cork status of an object in @@ -8517,7 +8517,7 @@ H5C__serialize_cache(H5F_t *f) * each entry in the cache to zero before we start the serialization. * This allows us to detect the case in which any entry is serialized * more than once (a performance issues), and more importantly, the - * case is which any flush depencency parent is serializes more than + * case is which any flush dependency parent is serializes more than * once (a correctness issue). */ { @@ -8674,8 +8674,8 @@ H5C__serialize_ring(H5F_t *f, H5C_ring_t ring) * are serialized correctly, it doesn't matter if we have to go back * and serialize an entry a second time. * - * These possible actions result in the following modfications to - * tha basic algorithm: + * These possible actions result in the following modifications to + * the basic algorithm: * * 1) In the event of an entry expunge, eviction or removal, we must * restart the scan as it is possible that the next entry in our @@ -8725,7 +8725,7 @@ H5C__serialize_ring(H5F_t *f, H5C_ring_t ring) * condition appears. * * Observe that either eviction or removal of entries as a result of - * a serialization is not a problem as long as the flush depencency + * a serialization is not a problem as long as the flush dependency * tree does not change beyond the removal of a leaf. */ while (!done) { |