Re: msleep(9) and recursed mutex

From: Daniel Eischen (deischen_at_freebsd.org)
Date: 10/11/04

  • Next message: Hans Petter Selasky: "Re: msleep(9) and recursed mutex" 
    Date: Mon, 11 Oct 2004 09:47:52 -0400 (EDT)
To: damien.bergamini@free.fr

    On Mon, 11 Oct 2004 damien.bergamini@free.fr wrote:

    > msleep(9) behaves strangely with recursed mutexes.
    > In the attached code, calling foo_f() will make the kernel hang for
    > two seconds.
    > It seems like msleep does not release the mtx mutex completely but
    > simply decrement its reference count by one. When calling msleep, the
    > mtx mutex is still held which prevent the interrupt from happening.
    > msleep will then return error code EWOULDBLOCK after two seconds.
    > If I remove calls to mtx_lock/unlock from function foo_g(), it works
    > without problem but this is not a solution since foo_g() can be
    > called outside of function foo_f().
    > Of course, the mtx mutex was created with the MTX_RECURSE flag set.

    First, don't use recursive mutexes -- they are (for now) a necessary
    evil.

    > Is it an expected behaviour? In msleep(9) it is said:
    > "The msleep() function is a variation on tsleep. The parameter mtx
    > is a mutex which will be released before sleeping and reacquired
    > before msleep() returns."
    >
    > Seems like the mutex is not *really* released if it recurses.

    Only one thread can take and own a recursive mutex, not multiple
    threads. An interrupt occurs in a different thread, so it cannot
    lock a mutex that it doesn't own. As you suggest, the only way
    this could work is if msleep() set the recurse count to zero and
    restored it back to its original value once it was awoken.

    I think it's great (a feature) that the use of recursive mutexes
    breaks when used with interrupts!

    Really, you want to be using condition variables. Use a mutex
    to protect your data and use cv_{timed}wait{_sig}() to sleep.
    When the interrupt occurs, you use cv_signal() or cv_broadcast()
    to wake up any waiters. 

    -- 
DE
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: Hans Petter Selasky: "Re: msleep(9) and recursed mutex"

    Relevant Pages

    • 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 ... adaptive or spin mutex. ... spin then IPL is raised to the specified level for spin ...
      (comp.unix.solaris)
    • 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. ... Giant is a special mutex that should not be used in properly ...
      (freebsd-hackers)
    Loading