FreeBSD spinlock - compatibility layer

[John Baldwin]

On Wednesday, May 22, 2013 12:32:45 pm Alfred Perlstein wrote:
> On 5/22/13 11:15 AM, John Baldwin wrote:
> > On Wednesday, May 22, 2013 9:27:16 am Alfred Perlstein wrote:
> >> On 5/22/13 9:05 AM, John Baldwin wrote:
> >>> Probably not.  For example, on FreeBSD you want your driver lock to be
> >>> preempted by an interrupt to avoid higher interrupt latency for filter
> >>> handlers.  Most drivers should not need temporary pinning.  If they want to
> >>> pin work to threads they should bind threads or IRQs to specific CPUs, not
> >>> rely on temporary pinning.
> >>>
> >> I know how it works in FreeBSD.
> >>
> >> I think that a compatibility layer should first and foremost aim for
> >> compatibility, not speed at expense of expected semantics.
> > The problem with this is that whatever code runs under this layer also has to
> > cooperate with the rest of the system.  Blindly using spin locks does not do
> > that.  Also, I think my entire point is about "expected semantics".  People
> > should think about the actual semantics they need in a driver, not just assume
> > that whatever side effects they get from the primitives and APIs provided on
> > one platform defines the semantics they need.  I still assert that in terms of
> > what a device driver actually expects, a regular mutex will provide the correct
> > semantics.
> >
> I agree with your assertion that what we have MTX_DEF should work for 
> drivers for the cases we have.
> 
> I do believe though that any kernel dev outside FreeBSD will expect 
> certain semantics from a spin mutex though.

No, not on Solaris.  Probably not on some dinosaur UNIXes (Irix had adaptive
mutexes for example).

-- 
John Baldwin