- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does anyone have a good example of using concurrent_hash_map::erase()?
I have been trying to get this working for the last week, and it appears that it will let me erase a key twice (returns tru in both threads), even though the documents indicate otherwise. Also how are you supposed to when to free the contents of the hash element?
For instance:
tbb::concurrent_hash_map
some threads:
tbb::concurrent_hash_map
if(my_map.insert(acc_w, new_Key)) {
acc_w->second = new Item();
}
some more threads:
if(my_map.erase(acc_w, some_Key)) {
// get here multiple times for same Key
// don't know what pointer is to free it - could do a find and stash pointer, but since Keys
// can be reused, the contents could change between the find() and the erase()
}
I also tried defining the map just as:
tbb::concurrent_hash_map
But couldn't get this working as Item has dynamically allocated data members in it, and despite putting in a copy constructor and assignment operators couldn't get it to work.
thanks for any assistance.
Simon Cope
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Let me check my understanding. So you are saying that a thread, after acquiring segment and chain lock and finding the item of interest, would not acquire item lock but instead queue itself into a waitlist for the item, and release those locks. And then what? Before starting to acquire the item lock, the thread will need to check if the lock is still valid, which in your vision seem to be equivalent of the thread still being in the waitlist. The question is, how the waitlist consistency is preserved - by yet another lock?
Yes, I think you could try. The current code of the hash map should be platform-neutral I think, except might be for some workarounds of platform-specific issues. For atomic operations, tbb::atomic should suffice. If some loads or stores need fences, there are __TBB_load_with_acquire and __TBB_store_with_release functions for that purpose.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Raf,
We received your contribution and Anton is evaluating it; and we will share the results here. Thank you very much for providing your feedback and ideas, and demonstrating a good example of community collaboration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We fixed "guarantee that erasing by accessor will erase the exact element the accessor points to" and deadlock which occurs for insert() while holding another accessor by the same thread and concurrently looking for the same existing item.
I believe changes will be included in coming development release. There is also may be performance benchmarks in which indicated that the contribution is slower than current version of the container.
I'm not sure whether "garbage collector" for the container and optional "blocking style" of erasing will be implemented because they require additional member of node structure at least. Though, I think they could be useful.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately, the target has moved in tbb20_20080512oss_src.
Before I try to merge both if I still feel like doing so myself, here are my changes relative to tbb20_20080408oss_src, for anyone interested.
(Added) Also see thread "Possible deadlock in TBB concurrent_hash_map".
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »