On February 27, John Baldwin (jhb@FreeBSD.org) committed a new sleep queue abstraction framework for FreeBSD. These queues are bound to wait channels, allowing fancy things like property inheritence, signal interrupts (bound to whole queues) and timeout capabilities.

Commit message
--------------------------------------------------------
Add an implementation of a generic sleep queue abstraction that is used
to queue threads sleeping on a wait channel similar to how turnstiles are
used to queue threads waiting for a lock. This subsystem will be used as
the backend for sleep/wakeup and condition variables initially. Eventually
it will also be used to replace the ithread-specific iwait thread
inhibitor.

Sleep queues are also not locked by sched_lock, so this splits sched_lock
up a bit further increasing concurrency within the scheduler. Sleep queues
also natively support timeouts on sleeps and interruptible sleeps allowing
for the reduction of a lot of duplicated code between the sleep/wakeup and
condition variable implementations. For more details on the sleep queue
implementation, check the comments in sys/sleepqueue.h and
kern/subr_sleepqueue.c.
--------------------------------------------------------

Announcement (sort of)
--------------------------------------------------------
On Friday 27 February 2004 01:52 pm, John Baldwin wrote:
> jhb 2004/02/27 10:52:44 PST
>
> FreeBSD src repository
>
> Modified files:
> sys/conf files
> sys/ddb db_ps.c
> sys/kern kern_condvar.c kern_sig.c kern_synch.c
> kern_thread.c sched_4bsd.c sched_ule.c
> sys_generic.c vfs_subr.c
> sys/sys condvar.h proc.h sched.h systm.h
> Log:
> Switch the sleep/wakeup and condition variable implementations to use the
> sleep queue interface:

There should be little user-visible effect from this change. Under load one
can trigger a new diagnostic message (soon to become an assertion, but it's a
diagnostic for now) about mismatches of msleep() wait channels and lock
pointers. The one case I have seen is that vm_page_sleep_if_busy() triggers
a diagnostic as it sleeps on a vm_page * while holding the page queues mutex
but some other thread is already sleeping on that address while holding no
lock (implicitly using Giant for synchronization). If you do get any weird
crashes, be sure to turn on INVARIANTS and WITNESS (with spin mutex checking
on, i.e. no WITNESS_SKIPSPIN) to see if you can get a less obscure panic
message. All of the bugs I found during testing were found by INVARIANTS +
WITNESS and when found in that manner they are a lot easier to locate and
fix. Thanks.
--------------------------------------------------------

Sleep queue abstraction code