Section 20.1. Overview of Task Queues

20.1. Overview of Task Queues

It is common for you, the kernel programmer, to postpone the processing of some tasks and delegate their execution to another kernel thread. There may be several reasons for doing this:

• You have a task that isn't time-critical, but a current code path that is.

• You have a task that may require grabbing locks that a thread already holds.

• You have a task that needs to block (for example, to wait for memory), but you have a thread that cannot block in its current context.

• You have a code path that can't complete because of a specific condition but also can't sleep or fail. In this case, the task is immediately queued and then is executed after the condition disappears.

• You just want to launch multiple tasks in parallel.

In all these cases, you need, in essence, to execute a piece of code (task) in a different context, where context usually means another kernel thread with a different set of locks held and, possibly, a different priority.

Until introduction of task queues in Solaris 8 there was no generic OS facility for such in-kernel context change. Every subsystem used its own ad hoc mechanisms, usually utilizing "worker threads" together with a list of jobs to give them. The task queues interface abstracts common code out of these mechanisms and substitutes a simple way of scheduling asynchronous tasks.

A task queue consists of a list of tasks, with one or more threads to service the list. If a task queue has a single service thread, all tasks are guaranteed to execute in the order in which they were dispatched. Otherwise, they can be executed in any order. Note that since tasks are placed on a list, execution of one task should not depend on the execution of another task lest deadlock should occur. A task queue (taskq) created with a single servicing thread guarantees that all tasks are serviced in the order in which they are scheduled.