Jason Thorpe wrote:
> 
> On Thu, 29 Jul 1999 23:47:21 +0200
>  Stefan Grefen <Stefan.Grefen@tantau.com> wrote:
> 
>  > Missing:
>  >  void cpu_simple_lock_destroy(__volatile struct simplelock *alp);
>  >                This function, inline function, or macro destroys
>  >                    the lock (a NOP on most architectures)
>  >                    With diagnostic/debug takes care of cpu lock-counts,
>  >                     if the lock is destroyed locked.
> 
> Ummm...
> 
>         (1) I said that I had already addressed the issue facing
>             the PA-RISC.
> 

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).

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.

>         (2) This would require simple_lock_create(), as well, and would
>             mean that simple locks could not be embedded into structures,
>             and could not be statically allocated/initialized.

I don't think so. In most architectures  cpu_simple_lock_destroy is a NOP
without DIAGNOSTIC or LOCK_DEBUG. In those cases it ensures the lock is not
reused. 
Static locks are never freed, so it is not an issue there.
With some architectures some dynamic initialization may be needed. But I think
it can be hacked into the framework there (initialize on first use).
We just have to provide static initialization macros.
On the other hand we can't afford 64 bytes or more per spinlock (like
on a PA-Risc) so something has to be done.

Stefan

> 
>         -- Jason R. Thorpe <thorpej@nas.nasa.gov>