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 <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
