On Wed, Nov 17, 2010 at 07:26:04AM -0500, Thor Lancelot Simon wrote: > On Wed, Nov 17, 2010 at 12:30:59PM +0100, Johnny Billquist wrote: > > > > There are obviously a lot of calls to mutex_enter and mutex_exit with > > spin mutexes... > > Indeed there are. I don't underestand what Matt said about this. When > I was converting /dev/crypto to mutexes I am pretty sure it was explained > to me that the _spin forms of the calls were simply optimizations for when > the programmer knew the mutex to be a spin mutex due to the IPL at which > it was declared. That is, I had a a pile of driver code full of mutex_enter > and mutex_exit which were on a high-IPL mutex and I simply converted it all > to mutex_spin_enter and mutex_spin_exit with qsubst. > > Perhaps the rule is that if you take the mutex with spin_enter you must > release it with spin_exit. That would make some sense. But I'd love some > clarity on this point.
You can release it with either call, mutex_spin_ is just a way to avoid additional atomic operations. The ususal case is adaptive mutex, but stuff like the dispatcher/scheduler makes use of spin mutexes exclusively and the fast path versions were invented for that. (Because you can measure the effect with benchmarks :-). Is Solaris -- the API we copied -- part of the motivation for allowing one call to lock/unlock both types of mutex must have been to hide the structure of the machine. But for us we hide the machine at a different level and having say mutex_enter handle both types of lock is really a convenience thing so locks can be passed about by pointer. > > Also a fair number of calls to mutex_spin_exit with the spin lock not > > appearing to be held (I actually set and clear a bit to indicate if the > > mutex is held, in addition to bumping the IPL). > > This *does* seem like a bug. > > -- > Thor Lancelot Simon t...@rek.tjls.com > > "We cannot usually in social life pursue a single value or a single moral > aim, untroubled by the need to compromise with others." - H.L.A. Hart
