Cryptic Error in concurrent_hash_map

[Mark_P_Neyer]

Hello,

We have been using the tbb 2.1 libraries successfully for some time now, and we are now trying to switch to 2.2. I am using boost shared pointers to hang on to concurrent_hash_maps. When the last reference to one of these maps is deleted, the map tries to clear itself and asserts with the following message:

"rehashing is not finished until serial stage due to concurrent or terminated operation"

I have no idea what that means. Any help would be appreciated.

[Bartlomiej]

I'm not sure, but AFAIK Boost "shared pointers" are neither MT-safe nor a useful pattern for MT programming.
Possibly the Boost library tries to delete the hash map unaware that other threads still use it?

[Anton_M_Intel]

Quoting - markpneyer

"rehashing is not finished until serial stage due to concurrent or terminated operation"

Bartlomiej is right. Please make sure that the map is not accessed by any concurrent operation during call to clear() or destruction. Another part of the message should be rather written as "unexpectedly terminated operation", i.e. when a thread terminates unexpectedly.
However, since TBB2.1 works fine for you, the assertion for the new version sounds suspiciously. I would appreciate if you could send me a small reproducer.

[RafSchietekat]

Quoting - Bartlomiej

I'm not sure, but AFAIK Boost "shared pointers" are neither MT-safe nor a useful pattern for MT programming.

It depends on what you mean by thread-safe, but they seem quite useful to me?

[Mark_P_Neyer]

Quoting - Anton Malakhov (Intel)

Bartlomiej is right. Please make sure that the map is not accessed by any concurrent operation during call to clear() or destruction. Another part of the message should be rather written as "unexpectedly terminated operation", i.e. when a thread terminates unexpectedly.
However, since TBB2.1 works fine for you, the assertion for the new version sounds suspiciously. I would appreciate if you could send me a small reproducer.

It's my understanding that the map is only accessed by one thread in its lifetime. (Originally we had planned to access it from multiple threads but those plans were scrapped. C'est la vie. ) Data is copied out of the table, and that data is passed on to other threads, but the table structure itself is only accessed from a single thread.

The crash is not happening when a thread terminates, it happens when a shared pointer's value is changed. This causes the old value's reference count to go to zero, and thus the concurrent_hash_map is erased.

It's easily reproducible for us; I will try to recreate the error in a simple app to see if i can reproduce the problem in non-proprietary code.

[Anton_M_Intel · Accepted solution]

Quoting - Mark P Neyer

Data is copied out of the table, and that data is passed on to other threads, but the table structure itself is only accessed from a single thread.

It seems the problem is in broken copy constructor that doesn't work well in some circumstances. Please, try constructor that takes iterators instead. We'll fix the error in the next release.

BTW, sure, it is strange that you use concurrent container for single thread access... Anyway, thanks for reporting the problem!