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_at_elischer.org> 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