Subject: Re: SMP API things, take 2
To: Stefan Grefen <Stefan.Grefen@tantau.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 07/29/1999 15:38:24
On Fri, 30 Jul 1999 00:21:40 +0200
Stefan Grefen <Stefan.Grefen@tantau.com> wrote:
> I checked the mail and can't find it (besides the 0/1 issue)
> On PA-Risc a lock must be cache-line sized. You don't want a lock per page
> or so. HPUX creates a hash table with physical locks. When a spinlock is
> initialized it is entered into the hashlist (by address) multiple spinlock
> share a physical lock. This reduces memory demand by an order of magnitude.
> Having a definite end on life time helps a lot here (esp. if the lock is
> still locked when discarded).
Aha, I see what you are saying now. So, in this case, locking one thing
might lock N other things, too? That's unfortunate; it greatly complicates
the case where you want to lock multiple things (using an ordered locking
protocol, of course :-)
My solution was to tell the compiler to align the lock_data (according
to Bill Sommerfeld, the atomic operations will work if 16-byte aligned,
so the compiler can do this with a simple __attribute__ directive).
> It is also a great help in debugging, without it the cpu-lock will go
> astray and its hard to figure out where the locks are lost. This function
> would be NOP in the normal case, but could complain if a lock is returned
> locked or just account the cpu lock count.
LOCKDEBUG already has checks for this; if you free an object with an
embedded lock and it is already lock, it complains at you.
-- Jason R. Thorpe <email@example.com>