From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Tatsuo Ishii" <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 7.1 vs. 7.2 on AIX 5L |
Date: | 2002-01-15 17:14:12 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA41EB4B2@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> NOTICE: LockRelease: no such lock
>
> I'm afraid now the locking is broken. Will look into more.
Next try would be _check_lock (found in sys/atomic_op.h):
Description (from man page)
The _check_lock subroutine performs an atomic (uninterruptible) sequence of
operations. The compare_and_swap subroutine is similar, but does not issue
synchronization instructions and therefore is inappropriate for updating lock
words.
replace the TAS define with:
#define TAS(lock) _check_lock(lock, 0, 1)
> with LinuxPPC asm: 2m9.340s
> with cs: 10m11.15s
> with fetch_and_or: 3m55.19s
with _check_lock: 3m29.990s
I think that the culprit may also be the S_UNLOCK (use _clear_lock) ?
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-01-15 17:34:24 | Re: 7.1 vs. 7.2 on AIX 5L |
Previous Message | Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= | 2002-01-15 16:48:09 | Re: PostgreSQL v7.2b5 Released |