On Thu, Oct 16, 2014 at 9:30 AM, Andres Freund <andres@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.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.
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