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

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-07-31 15:50, fr****@gmail.co m 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

[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

On Jul 31, 8:58*am, Erik Wikström <Erik-wikst...@telia. comwrote:

On 2008-07-31 15:50, [e-mail] m 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

[James Kanze]

On Jul 31, 3:58 pm, Erik Wikström <Erik-wikst...@telia. comwrote:

On 2008-07-31 15:50, [e-mail] m 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 objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <679ff0c8-6fea-485d-8058-61de1adf2ad8
@m73g2000hsh.go oglegroups.com> , ja*********@gma il.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.

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