Software interrupts are the most effective way of deferring the performance of activities to a future point in time. However, this deferral mechanism is very complicated to handle. Because softIRQs can be serviced simultaneously and independently on several processors, the handler routine of one and the same softIRQ can run on several CPUs at the same time. This represents a key contribution to the effectiveness of the concept — network implementation is a clear winner on multiprocessor systems. However, the handler routines must be designed to be fully reentrant and thread-safe. Alternatively, critical areas must be protected with spinlocks (or with other IPC mechanisms; see Chapter 5), and this requires a great deal of careful thought.

Tasklets and work queues are mechanisms for the deferred execution of work; their implementation is based on softIRQs, but they are easier to use and therefore more suitable for device drivers (and also for other general kernel code).

17kthread_should_stop() returns a true value if the softIRQ daemon is stopped explicitly. Since this happens only when a CPU is removed from the system, I will not discuss this case. I also omit preemption handling for the sake of clarity.

Before going into the technical details, a word of caution on the terminology used: For historical reasons, the term bottom half is often used to mean two different things; first, it refers to the lower half of the code of an ISR that performs no time-critical actions. Unfortunately, the mechanisms used in earlier kernel versions to defer the execution of actions was also referred to as the bottom half, with the result that the term is often used ambiguously. In the meantime, bottom halves no longer exist as a kernel mechanism. They were discarded during the development of 2.5 and replaced with tasklets, a far better substitute.

Tasklets are ''small tasks''that perform mini jobs that would be wasted on full processes.

Continue reading here: Generating Tasklets

Was this article helpful?

0 0