Re: Alpha tas() patch

Поиск
Список
Период
Сортировка
От Brent Verner
Тема Re: Alpha tas() patch
Дата
Msg-id 20001228161056.A16030@rcfile.org
обсуждение исходный текст
Ответ на Re: Alpha tas() patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Alpha tas() patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 28 Dec 2000 at 12:41 (-0500), Tom Lane wrote:
| 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.

what have I stumbled into :).  'damnit Jim!, I'm just a perl hacker.'

| 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.

I agree with this assessment from my reading of the asm docs so far. there
is also the (w)mb instruction whose importance/effect I'm not sure of...

| 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.

yes, WRT to the 'which bit', since __INTERLOCKED_TESTBITSS_QUAD takes 
as second arg, which is the bit to set.

| 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.

my understanding of the ldq_l/stc_q interaction, is: (forgive me if you
already grok all of this, I'm mostly thinking out loud.)

ldq_l $0, $1       # $0 = $1;
addq  $0,  1, $2   # $2 = $0 + 1;
stq_c $2, $1       # $1 = $2;
cmpeq $2, $1, $3   # $3 = $2 == $1 ? 1 : 0

if $3 == 1 we successfully modified the locked value ($1). I /believe/ this
will hold true across multi-processors as well, as all of the builtins
I've seen asm for seem to have similar structure.

| BTW, is your machine single- or multi-processor?

single.
brent


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Assuming that TAS() will succeed the first time is verboten
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Alpha tas() patch