On Jul 31, 3:58 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-07-31 15:50, fra...@gmail.com wrote:
I have a hash_map with string as key and an object pointer
as value. the object is like
class{
public:
float a;
float b;
...
}
I have two threads, one thread is keep updating the
hash_map, add new or grab the object and update the value.
Another thread is retrieving the object and read the value
randomly.
It is ok if the reading thread get the stale value
sometimes, but not acceptable if reading corrupted value
inside the object.
For performance concern, I do not want to lock the hash_map
when two threads are doing as
add
find by key and grab the object and update the value inside the object
I will put a mutex inside the object to make sure the read
will not get corrupted value. However, I am little concerned
when one thread doing the find on the key while another
thread is adding a new item, which will change the size of
the hash_map.
In C#, if I do not lock a collection when doing iteration,
other action on the hash_map at the same time (as an add)
may cause the exception. I have a little concerned whether
the same problem could happen on C++ hash_map. I am using
Redhat with gcc, on ext/hash_map.
Please note that hash_map is not part of the C++ language and
as such it is not topical in this group.
It will be in the next version of the standard (under the name
unsorted_map), and is probably available pretty much everywhere
today, with slight differences.
Threading too will be in the next version of the standard.
What you should do is to read the documentation for you
implementation and see if inserting elements invalidates
iterators, for some containers it does not not. Also you want
to know if operations on the container are thread-safe or not.
If the operations are not thread-safe but insertions does not
invalidate iterators you only need a mutex around the
insertion and around the find operations, but not for the
update.
It's a node based container, so insertions shouldn't invalidate
iterators. On the other hand, I rather suspect that any thread
safety guarantees will be given at the level of the container,
and not at the level of any particular iterator into it. So he
probably needs to lock all access, regardless of how it occurs.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
