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