Re: Alpha tas() patch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Alpha tas() patch
Дата
Msg-id 5618.978025304@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Alpha tas() patch  (Brent Verner <brent@rcfile.org>)
Ответы Re: Alpha tas() patch  (Brent Verner <brent@rcfile.org>)
Список 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 по дате отправления:

Предыдущее
От: Brent Verner
Дата:
Сообщение: Re: Alpha tas() patch
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: configure in snapshout == configure.in