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(at)stone(dot)congenomics(dot)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(at)acm(dot)org |
| P.O. Box 314 | URL: http://www.congen.com/~bruc |
| Pennington, NJ 08534 | |
+-----------------------------+------------------------------------+