question about iterating hash_map

[frankw]

Hi,

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.

Thanks

 

[Erik Wikström]

Hi,

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. 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.

 

[frankw]

hash_map is not part of STL, but it is implemented in extension. What
I am asking is about ext\hash_map under gcc implementation.
Unfortunately, the header file does not give me any answer to this.

Does anyone happen to know this?

Thanks

 

[James Kanze]

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.

 

[Jerry Coffin]

[ ... ]

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.

Minor typo -- you undoubtedly meant "unordered_map". It's also currently
in TR1.

 

[tni]

The STL containers, including the hash map are not thread safe (against
concurrent read/write access). The following applies to most STL
implementations, including the GCC one:

http://www.sgi.com/tech/stl/thread_safety.html

(It would have been a really bad decision for the standard to impose
thread safety on the STL.)