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.
