Re: Question about LWLockAcquire's use of semaphores instead of spinlocks

"Robert E. Bruccoleri" <bruc@stone.congenomics.com> writes:
> Tom Lane writes:
>> If you're saying that we don't have an implementation of TAS for
>> SGI hardware, then feel free to contribute one.  If you are wanting to
>> replace LWLocks with spinlocks, then you are sadly mistaken, IMHO.

> This touches on my question. Why am I mistaken? I don't understand.

Because we just got done replacing spinlocks with LWLocks ;-).  I don't
believe that reverting that change will improve matters.  It will
certainly hurt on SMP machines, and I believe that it would at best
be a breakeven proposition on uniprocessors.  See the discussions last
fall that led up to development of the LWLock mechanism.

The problem with TAS spinlocks is that they are suitable only for
implementing locks that will be held for *very short* periods, ie,
actual contention is rare.  Over time we had allowed that mechanism to
be abused for locking fairly large and complex shared-memory data
structures (eg, the lock manager, the buffer manager).  The next step
up, a lock-manager lock, is very expensive and certainly can't be used
by the lock manager itself anyway.  LWLocks are an intermediate
mechanism that is marginally more expensive than a spinlock but behaves
much more gracefully in the presence of contention.  LWLocks also allow
us to distinguish shared and exclusive lock modes, thus further reducing
contention in some cases.

BTW, now that I reread the title of your message, I wonder if you
haven't just misunderstood what's happening in lwlock.c.  There is no
IPC semaphore call in the fast (no-contention) path of control.  A
semaphore call occurs only when we are forced to wait, ie, yield the
processor.  Substituting a spinlock for that cannot improve matters;
it would essentially result in wasting the remainder of our timeslice
in a busy-loop, rather than yielding the CPU at once to some other
process that can get some useful work done.
        regards, tom lane