Re: (Modified) Patch request for PostgreSQL 7.4 for HP-UX IA-64
| От | Tom Lane |
|---|---|
| Тема | Re: (Modified) Patch request for PostgreSQL 7.4 for HP-UX IA-64 |
| Дата | |
| Msg-id | 8592.1072220522@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | (Modified) Patch request for PostgreSQL 7.4 for HP-UX IA-64 ("ViSolve Open Source Team" <opensrc_support_hp@visolve.com>) |
| Список | pgsql-bugs |
"ViSolve Open Source Team" <opensrc_support_hp@visolve.com> writes:
> this is a modified and more focussed patch request for PostgreSQL for for H=
> P-UX
> 11i V2 for the Intel Itanium architecture (known to the PostgreSQL code as
> IA-64).=20
I looked into applying the TAS part of this patch now that Bruce has
finished revising the TAS code, but I do not believe it is right.
The tas() routine looks reasonable, but not this:
> +#define S_UNLOCK(lock) \
> + ( \
> + _Asm_mov_to_ar((_Asm_app_reg)_AREG_CCV, 1UL),\
> + (_Asm_cmpxchg((_Asm_sz)_SZ_W, _SEM_REL, \
> + (volatile slock_t*)lock, \
> + 0UL, (_Asm_ldhint)_LDHINT_NONE, \
> + (_UP_MEM_FENCE|_DOWN_MEM_FENCE)) =3D=3D 1) ? 1 : 0 \
> + )
In the first place, S_UNLOCK does not return a value. In the second,
I doubt that you need an xchg instruction at all --- can't you just
assign zero? (If you can't, then the gcc IA64 code is wrong,
because it uses the default version of S_UNLOCK.)
> +#define S_LOCK_FREE(lock) ( *(volatile slock_t*)(lock))
This is wrong too, unless you're not using the convention that zero
indicates a free lock.
regards, tom lane
В списке pgsql-bugs по дате отправления: