Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

Cryptic Error in concurrent_hash_map

Mark_P_Neyer
Beginner
318 Views
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.
0 Kudos
1 Solution
Anton_M_Intel
Employee
318 Views
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!

View solution in original post

0 Kudos
5 Replies
Bartlomiej
New Contributor I
318 Views
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?
0 Kudos
Anton_M_Intel
Employee
318 Views
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.
0 Kudos
RafSchietekat
Valued Contributor III
318 Views
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?
0 Kudos
Mark_P_Neyer
Beginner
318 Views
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.
0 Kudos
Anton_M_Intel
Employee
319 Views
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!
0 Kudos
Reply