Date: Wed, 24 Apr 2002 13:30:13 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Rob Anderson <rob@isilon.com> Cc: freebsd-hackers@freebsd.org Subject: RE: msleep and spin locks Message-ID: <XFMail.20020424133013.jhb@FreeBSD.org> In-Reply-To: <200204241701.g3OH1b291992@isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24-Apr-2002 Rob Anderson wrote: > I'm trying to debug a deadlock problem I'm seeing in a kernel module, and > I wonder if someone could answer some questions I had about spinlocks. > > We've got a model where we have interrupt threads hand off work entries > to kthreads (so that the interrupt threads aren't blocked for too long). > The interrupt thread enqueues a work entry for the kthread, then wakes > up the kthread. Then, the kthread processes the work entry. The work > queue is protected by a spin lock. You shouldn't be using spin locks for this. You really want a regular mutex. They will adaptively spin at some point when it is profitable to do so. spin mutexes should only be used in very low-level "true" bottom-half code. ithread handlers are not true bottom-half code for this definition. msleep() is not intended to work with spin mutexes, but only with sleep mutexes. I would just use a sleep mutex and a condition variable to do this (you can use msleep/wakeup if you wish though.) > - What are the ill effects of handing a spin lock to msleep? It won't work. If you were had WITNESS turned on it should have panic'd. > - I noticed that no one seems to use msleep with spin locks, nor have a > need to do so. This leads me to believe that this producer/consumer > programming model show above is incorrect. Should we be doing this > differently? Just use a sleep mutex instead of a spin mutex and you will be ok. If you've worked on solaris before, think of spin mutexes as Solaris' dispatcher locks. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020424133013.jhb>