On 3/30/09, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Marko Kreen wrote: > > > 1. Add memory barrier to ProcArrayAdd/ProcArrayRemove between pointer > > and count update. This guarantees that partial slots will not be seen. > > > > 2. Always clear the pointer in ProcArrayRemove and check for NULL > > in all "lockless" access points. This guarantees that partial slots > > will be either NULL or just-freed ones, before the barrier in > > LWLockRelease(), which means the contents should be still sensible. > > > > #1 seems to require platform-specific code, which we don't have yet? > > > > Marking the pointer as volatile should work.
No, "volatile" affects only compiler, we need to notify CPU. > > So #2 may be easier solution. > > Agreed. And more importantly, it puts the onus of getting it right into > CountActiveBackends, which is the one who's breaking the rules. We don't > necessarily need to clear the pointer in ProcArrayRemove either, the count > doesn't need to be accurate. Without reset in ProcArrayRemove we may use some ancient pointer that may point to garbage? I don't think it's good coding style to allow that to happen. Lockless operations are unobvious enough... Also, are there other functions that try lockless access on proc_array? -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
