On Tue, Mar 1, 2011 at 5:21 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> A spinlock can be used only for very short-term operation like >> read/write of some shared-variables. The operation on the queue >> is not short, so should be protected by LWLock, I think. > > There's no need to sleep while holding locks and the operations are very > short in most cases. The code around it isn't trivial, but that's no > reason to use LWlocks. > > LWlocks are just spinlocks plus sem sleeps, so I don't see the need for > that in the current code. Other views welcome.
The following description in in src/backend/storage/lmgr/README leads me to further think that the spinlock should not be used there. Because, in the patch, while the spinlock is being held, whole of the waiting list (if there are many concurrent running transactions, this might be large) can be searched, SetLatch can be called and elog(WARNING) can be called (though this should not happen). ---------------- * Spinlocks. These are intended for *very* short-term locks. If a lock is to be held more than a few dozen instructions, or across any sort of kernel call (or even a call to a nontrivial subroutine), don't use a spinlock. Spinlocks are primarily used as infrastructure for lightweight locks. They are implemented using a hardware atomic-test-and-set instruction, if available. Waiting processes busy-loop until they can get the lock. There is no provision for deadlock detection, automatic release on error, or any other nicety. There is a timeout if the lock cannot be gotten after a minute or so (which is approximately forever in comparison to the intended lock hold time, so this is certainly an error condition). ---------------- Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
