Re: how to achieve thread safety at element level in STL data
structures like hash map, vectors
On Dec 4, 3:22 am, grbgooglefan <ganeshbo...@gmail.com> wrote:
Our application uses the caching heavily to store the data from
databases & also the runtime orders information.
All these caches are built on STL hash map, vectors & maps and data
format is the structures.
There are multiple threads accessing these caches simultaneously for
reading the data as well as updating the data.
Whenever any thread accesses the cache, it locks that cache & finds
the required element. Does the actions required & unlocks the cache.
I am finding that this is causing the other threads to wait for longer
time because the locking is at cache level.
I would like to make this locking quite finer & granular, in such a
way that only the single structure which is to be updated is locked.
This is somewhat same as the row level locking in databases.
How do we achieve this level of granular locking?
It depends. If you're not inserting or erasing on the map, then
you don't need a lock on it; only on the individual elements.
If you are (and if you're using it as a cache, you probably
are), then you need two locks for each transaction, one on the
element, and one on the table. Basically, you grab the lock on
the table, get the element, grab the lock associated with it,
and release the lock on the table. To insert, a lock on the
table is sufficient, but to erase, you need a lock on both the
table and the object, then erase the object from the map,
release the two locks, and delete.
Note that as described above, the second thread trying to
acquire the lock on an already locked object will hold the table
locked. You might want to consider using pthread_mutex_trylock,
or its equivalent under your system, and backing off, releasing
the lock on the table, and trying again later, when you can't
get the lock. More complicated (and fairer) schemes are also
possible.
If I were doing this, I'd probably wrap the table, so that the
user didn't have to worry about this, and have the getter return
a reference counted smart pointer which releases the lock on the
object when the last pointer (of the set of reference counted
smart pointers) disappears. Boost::shared_ptr works well for
this, provided you provide an appropriate destructor object when
you create the pointer.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34