On Fri, Nov 19, 2010 at 9:29 AM, Andres Freund <andres@anarazel.de> wrote:
> On Friday 19 November 2010 15:16:24 Robert Haas wrote:
>> On Fri, Nov 19, 2010 at 3:07 AM, Andres Freund <andres@anarazel.de> wrote:
>> > So the complicated case seems to be !defined(HAS_TEST_AND_SET) which uses
>> > spinlocks for that purpose - no idea where that is true these days.
>> Me neither, which is exactly the problem. Under Tom's proposal, any
>> architecture we don't explicitly provide for, breaks.
> I doubt its that much of a problem as !defined(HAS_TEST_AND_SET) will be so
> slow that there would be noise from that side more often...
>
> Besides, we can just jump into the kernel and back in that case (which the TAS
> implementation already does), that does more than just a fence...
Eh, really? If there's a workaround for platforms for which we don't
know what the appropriate read-fencing incantation is, then I'd feel
more comfortable about doing this. But I don't see how to make that
work. The whole problem here is that API is designed in such a way
that the signal handler might be invoked when the lock that it needs
to grab is already held by the same process. The reason memory
barriers solve the problem is because they'll be atomically released
when we jump into the signal handler, but that is not true of a
spin-lock or a semaphore.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company