Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> First, I did this:
> -#define TAS(lock) _Asm_xchg(_SZ_W, lock, 1, _LDHINT_NONE)
> +#define TAS(lock) (*(lock) ? 1 : _Asm_xchg(_SZ_W, lock, 1, _LDHINT_NONE))
Seems reasonable, and similar to x86 logic.
> Then, I did this:
> - while (TAS(lock))
> + while (*lock ? 1 : TAS(lock))
Er, what? That sure looks like a manual application of what you'd
already done in the TAS macro.
> Of course, we can't apply the second patch as it stands, because I
> tested it on x86 and it loses. But it seems pretty clear we need to
> do it at least for this architecture...
Please clarify: when you say "this architecture", are you talking about
IA64 or PA-RISC? Is there any reason to think that this is specific to
HP-UX rather than any other system on the same architecture? (I'm sure
I can get access to some IA64 clusters at Red Hat, though maybe not
I don't have an objection to the TAS macro change, but I do object to
fooling with the hardware-independent code in s_lock.c ... especially
when the additional improvement seems barely above the noise threshold.
You ought to be able to do whatever you need inside the TAS macro.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Kohei KaiGai||Date: 2011-08-28 18:32:30|
|Subject: [v9.2] Object access hooks with arguments support (v1)|
|Previous:||From: Peter Eisentraut||Date: 2011-08-28 12:04:43|
|Subject: confusing invalid UTF8 byte sequence error|