On 21 nov. 2012, at 22:14, Ion Gaztañaga <igaztanaga@gmail.com> wrote: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 :-).
> 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.
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