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