On Thu, Oct 16, 2014 at 9:30 AM, Andres Freund <and...@2ndquadrant.com> wrote: > 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.
Sure, so, you reuse your existing barriers instead of adding new ones. Making it work sounds like a lot of work for an uncertain benefit though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
