By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,006 Members | 1,164 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,006 IT Pros & Developers. It's quick & easy.

question about iterating hash_map

P: n/a
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

Jul 31 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On 2008-07-31 15:50, fr****@gmail.com wrote:
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.

--
Erik Wikström
Jul 31 '08 #2

P: n/a
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

On Jul 31, 8:58*am, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-07-31 15:50, fra...@gmail.com wrote:
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.

--
Erik Wikström
Jul 31 '08 #3

P: n/a
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
Jul 31 '08 #4

P: n/a
In article <679ff0c8-6fea-485d-8058-61de1adf2ad8
@m73g2000hsh.googlegroups.com>, ja*********@gmail.com says...

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

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 31 '08 #5

P: n/a
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.)
Jul 31 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.