Subject: Re: auto-spl simple locks
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-kern
Date: 07/30/1999 14:58:58
On Fri, Jul 30, 1999 at 08:32:42AM -0700, Jason Thorpe wrote:
> 
>  > storing the old spl level in the lock like this adds the constraint that
>  > locks must be released in the reverse order of that in which they were
>  > acquired.  it also requires either that the spl level used for a lock be
>  > greater than or equal to the spl level used for any locks aquired before
>  > it, or that splraise() semantics be used for all levels in cpu_lock_spl().
>  > if we conclude that these constraints are acceptable, they should be
>  > enforced by LOCKDEBUG.
> 
> Hrm.  Yes, you're correct.  Ok, so I'm becoming inclined to abandon this
> approach, and just add the spl*() calls explicitly, as appropriate.

Aren't approximately the semantics Chuck describes (particularly "locks
must be released in the reverse order...") pretty much characteristic of
almost all Unix kernels that support SMP with fine-grained locking?

That is, perhaps it's not such a bad idea to move that way, with the
notion that it's much less painful to introduce such changes incrementally
rather than in one fell swoop, with all the _other_ SMP/concurrent 
execution in the kernel hair.