Re: Alpha tas() patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Alpha tas() patch
Date
Msg-id 5618.978025304@sss.pgh.pa.us
Whole thread Raw
In response to Re: Alpha tas() patch  (Brent Verner <brent@rcfile.org>)
Responses Re: Alpha tas() patch  (Brent Verner <brent@rcfile.org>)
List pgsql-hackers
Brent Verner <brent@rcfile.org> writes:
> I see this with the version of TAS() that you recently suggested, but not 
> with either of the versions I'd hacked up.

Hm.  Your second version might incorrectly appear to work because it's
not checking for stq_c failure.  The first one loops until it succeeds,
so if the deal is that stq_c might work sometimes but not always
(dependent on, say, cache miss effects) then that might explain why it
works.  Clearly there's more here to worry about than the available
documentation suggests.

Awhile back I received some mail from a guy at Compaq saying that a
taken branch between ldq_l and stq_c is no good, apparently because some
versions of the processor will clear the lock register when any transfer
of control occurs.  But it sounded like a not-taken conditional branch
is OK.  Nonetheless, it's interesting that the
__INTERLOCKED_TESTBITSS_QUAD macro doesn't use any branch at all between
those two instructions.  Maybe we should try it that way.

Is there any documentation on exactly what __INTERLOCKED_TESTBITSS_QUAD
is supposed to do?  It looks like it's computing which bit to set in the
quadword, but I'm not sure I'm interpreting the code correctly.

I'm going to instrument my version a little more to see exactly which
step is failing ... I suspect it's the stq_c result test but want to
prove that before trying alternatives.

BTW, is your machine single- or multi-processor?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Brent Verner
Date:
Subject: Re: Alpha tas() patch
Next
From: Peter Eisentraut
Date:
Subject: Re: configure in snapshout == configure.in