Fast single-reader many-writer concurrent hash table
79 views
Skip to first unread message
sbahra
Mar 15, 2015, 9:22:06 PM3/15/15
to lock...@googlegroups.com
Hi all,
I'd love your thoughts on http://backtrace.io/blog/blog/2015/03/13/workload-specialization/ or at least hope it's useful to some folks! I've been using this a few years now, and decided to spend some time documenting the mechanism. I saw some folks asked for this on this last last year. The implementation was targeting TSO environment, and has no atomic operations / barriers there. The original implementation is also targeting pure single-writer scenario (but extensions available to make it completely linearized, if there's interest in that).
I'd love your thoughts on http://backtrace.io/blog/blog/2015/03/13/workload-specialization/ or at least hope it's useful to some folks! I've been using this a few years now, and decided to spend some time documenting the mechanism. I saw some folks asked for this on this last last year. The implementation was targeting TSO environment, and has no atomic operations / barriers there. The original implementation is also targeting pure single-writer scenario (but extensions available to make it completely linearized, if there's interest in that).
Dmitry Vyukov
Mar 16, 2015, 3:55:17 AM3/16/15
to lock...@googlegroups.com
I don't see any mention of SMR in the Delete section. But I guess you
still require deleted elements to be recycled via SMR, right?
In general, this looks like a good example of limiting requirements
and them implementing an efficient solution for the limited problem.
Thanks for sharing!
Samy Al Bahra
Mar 16, 2015, 6:26:55 AM3/16/15
to lock...@googlegroups.com
On Mon, Mar 16, 2015 at 3:54 AM, Dmitry Vyukov <dvy...@gmail.com> wrote:
[...]
>
> The way you do compaction (Probe Sequence Modification) is very nice!
Glad you like it, and it is applicable to MPMC transformation as well. :-)
>
> I don't see any mention of SMR in the Delete section. But I guess you
> still require deleted elements to be recycled via SMR, right?
Correct.
>
> In general, this looks like a good example of limiting requirements
> and them implementing an efficient solution for the limited problem.
>
> Thanks for sharing!
No problem!
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google Groups "Scalable Synchronization Algorithms" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/lock-free/_HtxFwuQGPY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to lock-free+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/lock-free/CAEeQi3vxW-ZDvSgRPSKe314KWnm55U%3D-ivdprS%3DXJ8K1gSVZkQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
Samy Al Bahra [http://repnop.org]
[...]
>
> The way you do compaction (Probe Sequence Modification) is very nice!
>
> I don't see any mention of SMR in the Delete section. But I guess you
> still require deleted elements to be recycled via SMR, right?
>
> In general, this looks like a good example of limiting requirements
> and them implementing an efficient solution for the limited problem.
>
> Thanks for sharing!
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google Groups "Scalable Synchronization Algorithms" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/lock-free/_HtxFwuQGPY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to lock-free+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/lock-free/CAEeQi3vxW-ZDvSgRPSKe314KWnm55U%3D-ivdprS%3DXJ8K1gSVZkQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
Samy Al Bahra [http://repnop.org]
Reply all
Reply to author
Forward
0 new messages