during the regression test. The problem has been reproduced on two machine
but both of these are the same type of hardware and software. I also tried
to recreate the problem on other machines, on older version of AIX but I
couldn't.
After looked through pgsql-hackers mailing list, I focused on spin lock
issue to solve the problem. The easiest and may not be the best solution
for the problem is to give up HAS_TEST_AND_SET. This actually works.
One another and better solution for the problem is to use _check_lock() and
_clear_lock() as spin lock. Important thing here is to define S_UNLOCK()
with _clear_lock(). This will solve the so called "Compiler bug" issue
someone wrote on the mailing list.
We have some other API such as cs(), compare_and_swap() and fetch_and_or()
to do test and set on AIX, but any of these didn't solve my problem. I
wrote tiny testing program to see if we have any bug of these API of AIX,
but I couldn't see any problem except for compare_and_swap(). It seems that
you can not use compare_and_swap() for the purpose, as it would not work as
spin lock on any SMP machines I tested. I don't know the reason why cs()
nor fetch_and_or()/fetch_and_and() will not work with PostgreSQL on p690.
These worked with my testing program on all machines I tested.
Tomoyuki Niijima
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
- * $Id: s_lock.h,v 1.99 2002/06/20 20:29:52 momjian Exp $
+ * $Id: s_lock.h,v 1.100 2002/09/02 04:42:52 momjian Exp $
*
*-------------------------------------------------------------------------
*/
*
* Note that slock_t on POWER/POWER2/PowerPC is int instead of char
*/
-#define TAS(lock) cs((int *) (lock), 0, 1)
+#define TAS(lock) _check_lock(lock, 0, 1)
+#define S_UNLOCK(lock) _clear_lock(lock, 0)
#endif /* _AIX */