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

Dear Tom,Thank you for the explanation. I did not understand what was
going on in lwlock.c.My systems are all SGI Origins having between 8 and 32
processors, and I've been running PostgreSQL on them for about 5
years.  These machines do provide a number of good mechanisms for high
performance shared memory parallelism that I don't think are found
elsewhere.  I wish that I had the time to understand and tune
PostgreSQL to run really well on them.I have a question for you and other developers with regard to
my SGI needs. If I made a functional Origin 2000 system available to
you with hardware support, would the group be willing to tailor the
SGI port for better performance?
                Sincerely,                Bob
> 
> 
> "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
> 

+-----------------------------+------------------------------------+
| Robert E. Bruccoleri, Ph.D. | email: bruc@acm.org                |
| P.O. Box 314                | URL:   http://www.congen.com/~bruc |
| Pennington, NJ 08534        |                                    |
+-----------------------------+------------------------------------+