Re: [Boost-users] [Intrusive] unordered_set and thread safety

Hi Alexandre, Please, notify us if you will find one that meets your requirements. Thanks, Dmitriy. С уважением, Матисон Дмитрий. On 22 November 2012 12:41, Alexandre Hamez wrote:

On 21 nov. 2012, at 22:14, Ion Gaztañaga wrote:

...

El 18/11/2012 8:56, Alexandre Hamez escribió:

...

Hello,

I'm currently using intrusive:: unordered_set in a single threaded application. But now, I need to switch to a multi threaded application. As such, the unordered_set must be protected. I don't want to block the whole table with a single mutex. Thus, it would be fine to have a lock per bucket. Furthermore, intrusive:: unordered_set provides a bucket_traits mechanism to enable some customization. So, my question: is it possible to use bucket_traits to have a lock per bucket?

I don't think so. We can obtain the bucket from the value but there is no insert function taking a bucket as argument. That would be an easy way to get some paralelism, at least for insertions. Intrusive could guarantee that the bucket search can be done in parallel and the insert_in_bucket function could be called with a locked mutex.

We would need an erase_from_bucket function that does not return an iterator to the next remaining object, as that could provoke race conditions (the next remaining object can be in a different bucket).

It's an interesting optimization for Intrusive, but I'm afraid it's not trivial. Thanks for your answer. I thought so that it was no feasible in the current state of Intrusive. I have then no other choice than to find a (intrusive) concurrent hash map implementation, or worst, to write my own :-).

Best regards,

...

Best,

Ion

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Alexandre Hamez

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users