From owner-freebsd-hackers Wed Apr 24 10:32:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by hub.freebsd.org (Postfix) with ESMTP id 700B037B42C for ; Wed, 24 Apr 2002 10:31:06 -0700 (PDT) Received: (qmail 21058 invoked from network); 24 Apr 2002 17:31:05 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 24 Apr 2002 17:31:05 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g3OHV5v07391; Wed, 24 Apr 2002 13:31:05 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200204241701.g3OH1b291992@isilon.com> Date: Wed, 24 Apr 2002 13:30:13 -0400 (EDT) From: John Baldwin To: Rob Anderson Subject: RE: msleep and spin locks Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 <>< 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