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. 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. If people agree with that way forward, I'll go through the platforms. The biggest one missing is probably solaris with sun's compiler. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
