Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127



On Sat, Jan 24, 2009 at 3:14 PM, Julian Elischer <julian@xxxxxxxxxxxx> wrote:
Maksim Yevmenkin wrote:

Hans Petter,

Do mutexes sleep? No? So my code should be fine?

yes, regular mutexes sleep.

Yes and no.

This is a semantic thing..

They don't actually 'sleep', but they do deschedule the thread.

the difference is purely semantic.

Users of mutexes "agree" to never do anything that in indeterminately long
while holding the mutex so you are SUPPOSED to get control back in a "short"
period of time. Even if multiple mutexes have
dependencies on each other, the fact that none of them may wait
for a "long" time is suposed to guarantee that your thread should get
control again "shortly".

It is illegal to sleep while holding a mutex. This helps enforce
this (otherwise small) distinction.

A Sleep may wait for an arbitrary amount of time.. e.g. until reboot.
so doing so with a mutex held would break the agreement.

Effectively the only real difference is that the agreement
by users to not use a mutex when things may get slow.

Spin locks are even more strict..

BTW A mutex that is waiting on a thread on another processor
may spin for a short amount of time before taking the expensive
step of descheduling the thread.

yes, i guess i used "sleep" word too much and it became overloaded. as
i tried to explain in previous email, when i talk about "sleep" i
really mean de-schedule.

in any case, i sent another patch to Hans Petter (privately) which
hopefully addresses most of his concerns. as i understood, the biggest
was excessive amount of NG_XXX macros and node reference counting. all
of those are now mostly gone and the resulting code is more clean (or
so i hope).

i kept async design which allows to completely decouple netgraph from
usb2 and, like i said, it is a "good thing(tm)"

thanks,
max
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127
    ... They don't actually 'sleep', but they do deschedule the thread. ... Users of mutexes "agree" to never do anything that in indeterminately long while holding the mutex so you are SUPPOSED to get control back in a "short" period of time. ...
    (freebsd-current)
  • Re: weird thread behavior on itanium/hp-ux with pthread
    ... deduced using thread 0 timeout value that it went to sleep earlier ... than when poll was initiated. ... thread woke up. ... associated a condition variable with a mutex that serves no purpose. ...
    (comp.programming.threads)
  • Re: [RFC] locking.9
    ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
    (freebsd-current)
  • [RFC] locking.9
    ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
    (freebsd-current)
  • Re: msleep() on recursivly locked mutexes
    ... Further the idea that holding a mutex "except for when we sleep" is a generally ... first a blocking lock and later a sleeping lock, ... it is not always possible to drop the blocking lock ...
    (freebsd-hackers)