> One of the known limitations of the current mod_mem_cache > code is that it uses a single global mutex to serialize > cache additions and deletions. > > I thought the easy fix for this would be to extend the > cache's hash table to include a mutex for each hash > bucket. That would enable us to lock only one chain > in the hash table, rather than the entire table.
I had this exact discussion with Jeff Trawick a few months back. The primary concern was with the potentially large number of mutex that could bump up against some Unix system limitations. > APR mutexes are dependent on pools, though, and it's > probably undesirable (though not impossible) to add > a dependency on pools within the mod_cache hash > structures. > > So the other alternative I've been thinking of is to > use an algorithm based on atomic compare-and-swap > operations to allow thread-safe searches and updates > of each hash chain. I've found several references > to lockless, concurrent linked list algorithms that > might be suitable, for example > http://citeseer.nj.nec.com/harris01pragmatic.html > > Given an efficient means of synchronizing searches > and updates on a linked list, we could add a "search > for this entry and create it if it doesn't exist" > function to the mod_cache hash table implementation. > > Anybody have opinions on this? Sounds desirable but will be a bear to implement portably. Bill
