Re: Adaptive mutexes

From: Gavin Maltby (g_a_v_i_n.m_a_l_t_b_y_at_s_u_n.com)
Date: 01/23/04 

Date: Fri, 23 Jan 2004 11:07:01 +0000

Hi

Ragnar wrote:
> Hello
>
> If we intialise a mutex in Solaris to a spin mutex, then it has to be
> initialised with the interrupt level to be disabled while the mutex is
> being held.

Indirectly, I think. mutex_init(9F) says type must always be MUTEX_DEFAULT.
But if you quote an associated arg which is a cookie returned from a
previously registered interrupt then that contains the necessary info
for how the mutex should be (internally) initialized (to be either a kernel
adaptive or spin mutex. If you successfully acquire such a mutex on the
fast path (ie, acquire on first attempt) then IPL is not changed at all
(it will be at whatever level the interrupt happened at). If we have to
spin (not adaptively) then IPL is raised to the specified level for spin
(it may already be at that level if the interrupt happened at that level
anyway, it would only need real increase if a mutex is designed for use at
more than one level).

> But if we intialised a mutex with MUTEX_DEFAULT, and the owner is
> running on another processor, the mutex would spin. My question is: Is
> the IPL raised in this case, and if it is, how is it determined which
> level it must be raised to ?

No IPL won't be raised for the time it spins or at any time for adaptive
mutexes. There is no need - interrupts at different levels (though still
at adaptive levels) can use the same adaptive mutex without having to
shut one-another out; that because such interrupts are allowed to
block, so if a high IPL interrupt finds a lower interrupt has already
acquired the mutex we're not deadlocked - we can will our priority down
and block and resume when it's released.

Gavin

Relevant Pages

  • Re: esballoc() callbacks
    ... I'm wondering about soft interrupt issues and how the free ... You should create the mutex as any driver mutex using the driver's ... >other runs return buffers after a few minutes. ...
    (comp.unix.solaris)
  • Re: Suspending Threads
    ... the Interrupt method a) requires that you have a reference to the Thread object and b) causes an exception to occur in the thread. ... So while I agree that all three methods can accomplish essentially the same thing, I find that using Sleep/Interrupt is significantly inferior to the other two methods. ... For what it's worth, I also don't see mutex and event as being exactly equivalent, since the event is more a matter of signaling, while the mutex is an ongoing thing. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: scheduler (sched_4bsd) questions
    ... > Thread A holds a mutex x contested by Thread B and C and has priority ... > An interrupt thread I tries to lock mutex y owned by C. ... > However priority inheritance does not work since B needs to run first to ... if the interrupt happens after x is released then I's priority should ...
    (freebsd-arch)
  • Re: msleep(9) and recursed mutex
    ... When calling msleep, the ... > mtx mutex is still held which prevent the interrupt from happening. ... don't use recursive mutexes -- they are a necessary ...
    (freebsd-hackers)
  • Re: Adaptive mutexes
    ... >> If we intialise a mutex in Solaris to a spin mutex, ... >> initialised with the interrupt level to be disabled while the mutex is ... arg is basically saying "make sure it is safe to grab this lock from ...
    (comp.unix.solaris)
Loading