On 3/30/09, Heikki Linnakangas <heikki.linnakangas@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
