Is this "bounded staleness" the same as lazySet/putOrdered? On Tue, Jan 30, 2018 at 1:31 PM, Wojciech Kudla <[email protected]> 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, <[email protected]> wrote: > >> Tom Hart's thesis looks like a very comprehensive answer. >> >> Thanks. >> >> > On 28 Jan 2018, at 19.05, Duarte Nunes <[email protected]> >> 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 <[email protected]> >> 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 [email protected]. >> > 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 [email protected]. >> > 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
