From owner-freebsd-hackers Wed Apr 24 10: 2:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from isilon.com (isilon.com [65.101.129.58]) by hub.freebsd.org (Postfix) with ESMTP id 70B6537B41A for ; Wed, 24 Apr 2002 10:02:07 -0700 (PDT) Received: (from rob@localhost) by isilon.com (8.11.1/8.11.1) id g3OH1b291992 for freebsd-hackers@freebsd.org; Wed, 24 Apr 2002 10:01:37 -0700 (PDT) (envelope-from rob) Date: Wed, 24 Apr 2002 10:01:37 -0700 (PDT) From: Rob Anderson Message-Id: <200204241701.g3OH1b291992@isilon.com> To: freebsd-hackers@freebsd.org Subject: msleep and spin locks 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 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. Unfortunately, the kthread waits for work entries by calling msleep(). msleep() expects a regular sleep lock to be handed in, not a spin lock. I would *expect* that this would result in the kthread blocking interrupts when it calls mtx_lock_spin(), and since msleep() won't re-enable interrupts (as far as I know), I would expect total starvation of the kthread. But that's not what I'm seeing...I'm actually seeing the interrupt thread getting called, but it's blocking on the mtx_lock_spin(). The interrupt callback code looks like: mtx_lock_spin(&spin_lock); <--- blocking here *** /* Add a new work entry */ mtx_unlock_spin(&spin_lock); wakeup(channel); The kthread code looks like: for (;;) { mtx_lock_spin(&spin_lock); while ( /* Work queue is empty */ ) { msleep(channel, &spin_lock, PI_DISK, str, 0); } /* Remove a work entry */ mtx_unlock_spin(&spin_lock); /* Process the work entry we just removed */ } My questions to you: - What are the ill effects of handing a spin lock to msleep? - 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? Many thanks, Rob A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message