Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Apr 2002 10:01:37 -0700 (PDT)
From:      Rob Anderson <rob@isilon.com>
To:        freebsd-hackers@freebsd.org
Subject:   msleep and spin locks
Message-ID:  <200204241701.g3OH1b291992@isilon.com>

next in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204241701.g3OH1b291992>