Manual memory management for concurrent code

[Chris Vest]

Hi,

I know of two ways to do manual memory management in multi-threading code: hazard pointers and epochs.

Which one is generally considered the higher performance option?
Are there any other options that should be considered as well?
Are there any spicy trade-offs one should make sure to factor into the decision of which one to go with?

Thanks,
Chris.

[Duarte Nunes]

There's also Quiescent-State-Based Reclamation, which emerged in the context of RCU. Tom Hart’s 2005 thesis[1] provides a pretty comprehensive overview of these memory reclamation strategies.

Another approach to consider would be a sharded design a la Seastar[2], or some other approach leveraging the single writer principle (i.e., peer-to-peer communication based on SPSC queues) to decrease synchronization overhead.

[1] http://www.cs.toronto.edu/~tomhart/papers/tomhart_thesis.pdf

[2] https://github.com/scylladb/seastar

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Vest]

Tom Hart's thesis looks like a very comprehensive answer.

Thanks.

[Wojciech Kudla]

There's very interesting progress in that space happening lately. Some of that is being applied to the Linux kernel as new RCU implementation. Looks very promising. It's based on fast consensus using bounded staleness.

Have a look here:
https://lwn.net/Articles/745116/
And the paper:
http://ipads.se.sjtu.edu.cn/lib/exe/fetch.php? media=publications:consensus-tpds16.pdf

[Nikolay Tsankov]

Is this  "bounded staleness" the same as lazySet/putOrdered?

On Tue, Jan 30, 2018 at 1:31 PM, Wojciech Kudla <wojciec...@gmail.com> wrote:

There's very interesting progress in that space happening lately. Some of that is being applied to the Linux kernel as new RCU implementation. Looks very promising. It's based on fast consensus using bounded staleness.

Have a look here:
https://lwn.net/Articles/745116/
And the paper:
http://ipads.se.sjtu.edu.cn/lib/exe/fetch.php? media=publications:consensus-tpds16.pdf

On Sun, 28 Jan 2018, 19:35 Chris Vest, <mr.chr...@gmail.com> wrote:

Tom Hart's thesis looks like a very comprehensive answer.

Thanks.

> On 28 Jan 2018, at 19.05, Duarte Nunes <duarte....@gmail.com> wrote:
>
> There's also Quiescent-State-Based Reclamation, which emerged in the context of RCU. Tom Hart’s 2005 thesis[1] provides a pretty comprehensive overview of these memory reclamation strategies.
>
> Another approach to consider would be a sharded design a la Seastar[2], or some other approach leveraging the single writer principle (i.e., peer-to-peer communication based on SPSC queues) to decrease synchronization overhead.
>
> [1] http://www.cs.toronto.edu/~tomhart/papers/tomhart_thesis.pdf
> [2] https://github.com/scylladb/seastar
>
> On Sun, Jan 28, 2018 at 5:45 PM Chris Vest <mr.chr...@gmail.com> wrote:
> Hi,
>
> I know of two ways to do manual memory management in multi-threading code: hazard pointers and epochs.
>
> Which one is generally considered the higher performance option?
> Are there any other options that should be considered as well?
> Are there any spicy trade-offs one should make sure to factor into the decision of which one to go with?
>
> Thanks,
> Chris.
>
> --
> You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Dimitar Dimitrov]

There's also this paper: http://www.rdrop.com/users/paulmck/RCU/hart_ipdps06.pdf (Hart, McKenney, and Brown), which was somewhat of a follow up to Hart's thesis.

It's a short and concise performance analysis comparing QSBR, hazard pointers, epochs, and CAS-based (not wait-free) lock-free reference counting.