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
|
Список | 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 по дате отправления: