On 2015-05-31 08:00:44 -0400, Robert Haas wrote:
> On Sat, May 30, 2015 at 7:09 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2015-05-27 21:23:34 -0400, Robert Haas wrote:
> >> > Oh wow, that's bad, and could explain a couple of the problems we're
> >> > seing. One possible way to fix is to replace the sequence with if
> >> > (!TAS(spin)) S_UNLOCK();. But that'd mean TAS() has to be a barrier,
> >> > even if the lock isn't free - which e.g. isn't the case for PowerPC's
> >> > implementation :(
> >>
> >> Another possibility is to make the fallback barrier implementation a
> >> system call, like maybe kill(PostmasterPid, 0).
> >
> > It's not necessarily true that all system calls are effective
> > barriers. I'm e.g. doubtful that kill(..., 0) is one as it only performs
> > local error checking. It might be that the process existance check
> > includes a lock that's sufficient, but I would not like to rely on
> > it. Sending an actual signal probably would be, but has the potential of
> > disrupting postmaster progress.
>
> So pick a better system call?
It's not yet entirely clear what that'd be unfortunately. Maybe we could
use waitpid(PostmasterPid, status, WNOHANG) - afaics that should work.
> > I think we should just bite the bullet and require a barrier
> > implementation for all architectures that have spinlock support. That
> > should be fairly straightforward, even though distinctly unpleasurable,
> > exercise. And then use semaphores (PGSemaphoreUnlock();PGSemaphoreLock()
> > doesn't have the issue that spinlocks have) for --disable-spinlock
> > platforms.
>
> Like maybe this.
On second thought they're unfortunately not entirely suitable. While
we've had used semaphores in signal indirectly for a long while
(e.g. deadlock detector, sinval code etc), they're formally not
guaranteed to be signal safe.
Greetings,
Andres Freund
