Changes between Version 2 and Version 3 of rfc26_blockcache

Timestamp:

Dec 6, 2009, 2:40:40 AM (14 years ago)

Author:

tamas

Comment:

--

rfc26_blockcache

@@ -36 +36 @@
 
 
-Protecting the band level cache from the access of multiple threads may happen by using a per-band a mutex of the
+Protecting the band level cache from the access of multiple threads may happen by using a per-band mutex of the
 raster band, however using this second mutex may easily lead to deadlock situations as pointed out in #3324. To avoid this situation it would be much
 safer to use hRBMutex to protect the simoultaneous access to the per-band cache as well. In most cases when accessing the per-band
 cache, hRBMutex is also involved in various operations (like GDALRasterBlock:Touch, GDALRasterBlock:Internalize, 
-GDALRasterBlock::SafeLockBlock etc.) it would only require to extend the scope of this mutex by exposing hRBMutex to be
+GDALRasterBlock::SafeLockBlock etc.) it would only be required to extend the scope of this mutex by exposing hRBMutex to be
 accessed by GDALRasterBand.
 
-To select between the array based and the hashtable based approaches a nMaxCacheSize parameter is introduced for each band.
-When the array would exceed this size limit the hashtable based approach will be selected, and the hashtable is allocated
+To select between the array based and the hashtable based approaches a nMaxCacheSize parameter is introduced at the band.
+When the array would exceed this size limit the hashtable based approach is selected, and the hashtable is allocated
 to this initial size by default.