On 2014-10-16 09:19:16 -0400, Robert Haas wrote:
> On Thu, Oct 16, 2014 at 8:03 AM, Ryan Johnson
> <ryan.johnson@cs.utoronto.ca> wrote:
> > Why not use an RCU mechanism [1] and ditch the hazard pointers? Seems like
> > an ideal fit...
> >
> > In brief, RCU has the following requirements:
> >
> > Read-heavy access pattern
> > Writers must be able to make dead objects unreachable to new readers (easily
> > done for most data structures)
> > Writers must be able to mark dead objects in such a way that existing
> > readers know to ignore their contents but can still traverse the data
> > structure properly (usually straightforward)
> > Readers must occasionally inform the system that they are not currently
> > using any RCU-protected pointers (to allow resource reclamation)
>
> Have a look at http://lwn.net/Articles/573424/ and specifically the
> "URCU overview" section. Basically, that last requirement - that
> readers inform the system tat they are not currently using any
> RCU-protected pointers - turns out to require either memory barriers
> or signals.
Well, there's the "quiescent-state-based RCU" - that's actually
something that could reasonably be used inside postgres. Put something
around socket reads (syscalls are synchronization points) and non-nested
lwlock acquires. That'd mean it's nearly no additional overhead.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services