Is there any way to check if an iterator is really?

For two threads manipulating a container map, for example, what is the right way to check if the iterator remains valid (to improve performance)?
Or it would only be an indirect way to do this. Sample code for this:

#define _SECURE_SCL 1 //http://msdn2.microsoft.com/en-us/library/aa985973.aspx #define _SECURE_SCL_THROWS 1 #include "map" #include "string" #include "exception" #include "iostream" using namespace std; void main(void) { map<string, string> map_test; map<string, string>::iterator iter_map_test; map_test [ "AAAAA" ] = "11111"; map_test [ "BBBBB" ] = "22222"; map_test [ "CCCCC" ] = "33333"; iter_map_test = map_test.find ("BBBBB"); map_test.erase ("BBBBB"); try { string value = (*iter_map_test).second; } catch ( exception & e ) { cout << e.what() << endl; } catch ( ... ) { cout << "generic exception." << endl; } } 
+3
c ++ performance iterator stl
Jan 12 '09 at 16:36
source share
5 answers

std::map are not thread safe. You will encounter much more serious problems than invalid iterators if you have multiple threads modifying the same map. I don’t even think that you have a guarantee that you can read anything from the card while it is being changed by another body.

Some pages in STL and stream:

+9
Jan 12 '09 at 16:39
source share

If your STL does not offer a safe stream of std::map , Intel TBB offers a thread-safe concurrent_hash_map (pages 60 and 68).

By eliminating thread safety issues, std::map ensures that deletion does not invalidate iterators other than the deletion. Unfortunately, there is no is_iterator_valid() method to test the iterators you hold.

Perhaps something like hazard pointers will be implemented, and TBB also has some workarounds.

+3
Jan 12 '09 at 18:53
source share

If you know that one of the threads will only read the map, and the other can manipulate it, the simplest solution is that the read-only stream clones the card and iterates over the clone.

(Caution: I know the Java collection classes much better than I know STL, but that would be how I would do it in Java.)

+2
Jan 12 '09 at 16:39
source share

If you are implementing a read / write solution, then you may have a flag set that invalidates all reader iterators.

http://en.wikipedia.org/wiki/Readers-writer_lock

I would not write to a card without synchronization, as Josh and Paul Tomblin mentioned.

+2
Jan 12 '09 at 16:46
source share

Even you could find out if the pointer is valid, this will not solve your problem. You are sharing the only resource that is not a guarantor of exlusivelty. That is why it will fail.

It will fail in this thread sequence:

Thread0 ................................ Thread1

Get iterator-> it0

check that it0 is really

............................................. Get Iterator β†’ it1

............................................. make sure that it1 really .

Erase (it0)

............................................. Erase (it1)

You can add a semaphore to access the shared resource.

+1
Apr 17 '09 at 15:17
source share



All Articles