On 2014-10-16 09:19:16 -0400, Robert Haas wrote: > On Thu, Oct 16, 2014 at 8:03 AM, Ryan Johnson > <ryan.john...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers