Re: mutexes, locks and so on...

[Andrew Doran <ad%homeworld.netbsd.org@localhost>]

On Wed, Nov 17, 2010 at 12:30:59PM +0100, Johnny Billquist wrote:
> On 11/17/10 11:38, Johnny Billquist wrote:
> >On 11/17/10 05:15, Matt Thomas wrote:
> >>
> >>On Nov 16, 2010, at 8:04 PM, Johnny Billquist wrote:
> >>
> >>>On 2010-11-17 04:52, Matt Thomas wrote:
> >>>>
> >>>>Not true. Spinlocks must enter through mutex_spin_enter and adaptive
> >>>>mutexes
> >>>>enter through mutex_enter. The corresponding is true for exiting as
> >>>>well.
> >>>>The only reason mutex_vector_{enter,exit} is called to cause a panic.
> >>>
> >>>That may be true in theory, but I happen to know (now) that it's not
> >>>true in reality. I've found atleast one place in the kernel where
> >>>this is done.
> >>
> >>Then that is a bug and should be fixed. File a PR.
> >
> >Ouch. Should I also file bugs for mutexes that are released, but already
> >appear to be free? Because that also happens.
> >
> >I actually wonder if it is a bug, or just a chosen design. I'd rather
> >say we should get rid of the mutex_spin_{} functions, since the kernel
> >is so confused about the whole thing anyway.
> >
> >I'm adding a bunch of counters now, and will come back with how often
> >these things are abused in a minute...
> >
> >>>Oh, and mutex_vector_exit will not cause a panic, just because it was
> >>>called from mmutex_spin_exit with a adaptive mutex. mutex_vector_exit
> >>>will simply just handle it as an adaptive mutex, and release it.
> >>
> >>That should probably be fixed.
> >
> >How? mutex_vector_{enter,exit} have been written to handle both spin and
> >adaptive mutexes. And it don't know that it might have been called from
> >mutex_spin_{} with an adaptive mutex. It might in fact be the only
> >function available for both kinds... You don't have to write your own
> >mutex_[]_{enter,exit} functions, and if not, the mutex_vector ones will
> >be used directly.
> 
> Some results from having put in a bunch of counters. This on a
> freshly booted system:
> 
> mutex exit adapt with unlocked                    0        0 misc
> mutex exit spin with unlocked                  1004        2 misc
> mutex enter spin with lock                        0        0 misc
> mutex exit adapt with spin                    41864       92 misc
> mutex exit spin with adapt                        0        0 misc
> mutex enter adapt with spin                   40935       89 misc
> mutex enter spin with adapt                       0        0 misc

It would be interesting to learn what's giving you those results.
On a running and very busy system mutex_enter/exit are "rarely" called
with spin mutexes as argument.