Date: Sat, 24 Jan 2009 15:31:29 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 Message-ID: <bb4a86c70901241531j59e3bf9s6505fb48754f57cc@mail.gmail.com> In-Reply-To: <497BA0F2.5080004@elischer.org> References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> <bb4a86c70901231514x7696e457k3a6dc0e59d4daed7@mail.gmail.com> <200901240952.21670.hselasky@c2i.net> <bb4a86c70901240138g6a221fd4rbab3945193e4617@mail.gmail.com> <497BA0F2.5080004@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 24, 2009 at 3:14 PM, Julian Elischer <julian@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70901241531j59e3bf9s6505fb48754f57cc>