Date: Wed, 28 May 2008 08:17:46 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: ilya@po4ta.com Cc: freebsd-drivers@freebsd.org Subject: Re: Synchronization in drivers (after SMP improvements) Message-ID: <20080528.081746.1683967403.imp@bsdimp.com> In-Reply-To: <483D62D0.6070800@po4ta.com> References: <600706.33129.qm@web51403.mail.re2.yahoo.com> <483D62D0.6070800@po4ta.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <483D62D0.6070800@po4ta.com>
Ilya Bobir <ilya@po4ta.com> writes:
: Alexander Popov wrote:
: > Hi, Benjamin, also Ilya,
: >
: >
: > Thanks for your quick responses. mtx_sleep() would
: > definitely help. Does it mean that user process executing in kernel space is
: > guaranteed not to be preempted between mtx_lock() and mtx_sleep()? Because then
: > I would get a sleeping thread with
: > non-sleepable mutex anyway... or have I been in application
: > development for too long? :-)
: > Regards,
: >
: > Alexander.
: >
: >
:
: According to locking(9) (" Context mode table." at the very bottom) the
: only type of mutex you can use in your interrupt handler is a spin
: mutex. And you are trying to synchronize with an interrupt handler.
: So, the sc->mtx ought to be a spin mutex. While a spin mutex is held
: all interrupts on the current CPU are blocked or deferred (mutex(9),
: DESCRIPTION fifth paragraph) and the thread holding the mutex will not
: be preempted.
That's only true of 'fast' interrupt handlers. Normal Ithread
interrupt hanlders, mutexes are fine since you aren't really in an
interrupt context. If this is indeed a usb device driver, then the
context for a callback routine for an interrupt endpoint really is a
taskqueue...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080528.081746.1683967403.imp>