Re: how to achieve thread safety at element level in STL data
structures like hash map, vectors
On Dec 5, 8:13 am, yurec <Yurij.Zha...@materialise.kiev.ua> wrote:
On Dec 4, 4: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?
Thoughts please.
Are you sure, that such thread safe cache which you try to implement
by yourself will be more efficient, than using database (if it's on
the same hdd as application)?As I know f.e. Oracle has very efficient
row locks.Anyway I'm very interesting in such problem(i thought about
such task a year ago, but the only thing, which came to my mind was to
have some read-write maps in a bigger map.I found that it was bad idea
and decided not to use such cache).If you get efficiency growth,
please tell me (us) it in percents.
It depends on whether the updates have to be persistent. From
his description, I gather that this is not the case. Updating a
record with Oracle always involves at least one disk write (and
I don't think that Oracle has an option to turn off
synchronization for this); updating a record in a hash table
doesn't involve any. In the simplest case (i.e. incrementing a
counter), this could mean a difference of several orders of
magnitude: something like a microsecond or two (including the
mutex lock) in memory, 10 milliseconds with the synchronized
disk read.
--
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