On Sep 8, 2006, at 6:45 AM, Andrew Doran wrote:

> I agree that it's ugly but I also think we'd be shooting ourselves  
> in the
> foot by raising the cost of getting this up and running. I'd prefer  
> have
> mutex_link()/exit_linked() available as a compromise. If we have the
> resources to alter the underlying implementation to deal with this  
> correctly
> later, then at near zero cost we can stub those out and leave them  
> there for
> a while for kernel modules that still know about them.

Can you explain to me again how the link/exit_linked stuff will work?   
I want to make sure I have my head wrapped around it properly. :-)

> It's there for compatibility and equates to MUTEX_SPIN. Our model is  
> quite
> different, so it's not documented it in the manual page for that  
> reason. I
> can see how it could be useful if we were ever to do interrupts as  
> threads
> or similar, so I'll document it. Please note I'm not suggesting that!

Ok.  Let's go ahead and make the different mode indicators distinct  
values so we have the option to change their defaults later without  
making an ABI change.  I think it could be argued that MUTEX_DRIVER  
should mean:

- MUTEX_SPIN if ipl != IPL_NONE
- MUTEX_DEFAULT if ipl == IPL_NONE

(Consider a driver that uses no interrupts or callouts at all...)

>> The documentation implies that holding an adaptive mutex across a
>> sleep is not allowed.  Actually, it is allowed, but of course leads  
>> to
>> increased contention for the mutex.  That said, some things might  
>> need
>> to hold other things off while it sleeps waiting for some condition,
>> so it should be officially allowed by the API.
>
> In general it's something that you really want to avoid and that's  
> what the
> paragraph was intended to convey. I'll re-word it.

True, you want to avoid it, but then again you'd want to avoid it with  
lockmgr() exclusive locks, too :-)  Yet it is currently allowed.   
Sometimes it's unavoidable ("need to prevent access to a device while  
the firmware re-flashes", for example).

>> I don't think we should have adaptive vs. spin-only rwlocks.  Solaris
>> only has sleeper-style rwlocks, and we ourselves only have  
>> spinlockmgr
>> () for a few special cases.
>
> I'd like to do that, it would remove a lot of complication. Looking  
> at it
> now, the proclist lock is easy enough to deal with, but some pmaps  
> also use
> spinlockmgr() and I'm not sure how to deal with those yet.

Those can probably just become regular rwlocks ... I don't think there  
any danger in letting those code paths sleep any longer.

Chuq -- any comments on this?

> Right, that was one of my goals. For LOCKDEBUG I'm tempted to argue  
> but I
> can think of a couple of ways around it.

Eventually, I'd like LOCKDEBUG to be able to become a run-time boot  
flag.  This can be arranged by cleverness in mutex_init().

-- thorpej