Re: Alpha tas() patch

From: Brent Verner <brent(at)rcfile(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Alpha tas() patch
Date: 2000-12-28 21:10:56
Message-ID: 20001228161056.A16030@rcfile.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On 28 Dec 2000 at 12:41 (-0500), Tom Lane wrote:
| Brent Verner <brent(at)rcfile(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-12-28 21:33:56 Re: Alpha tas() patch
Previous Message Patrick Dunford 2000-12-28 20:56:57 Connecting across internet

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2000-12-28 21:33:56 Re: Alpha tas() patch
Previous Message Tom Lane 2000-12-28 17:41:44 Re: Alpha tas() patch