与许多其它多线程 UNIX® 内核所采取的模式类似， FreeBSD 会赋予中断处理程序独立的线程上下文， 这样做能够让中断线程在遇到锁时阻塞。 但为了避免不必要的延迟， 中断线程在内核中， 是以实时线程的优先级运行的。 因此， 中断处理程序不应执行过久， 以免饿死其它内核线程。 此外， 由于多个处理程序可以分享同一中断线程， 中断处理程序不应休眠， 或使用可能导致休眠的锁， 以避免将其它中断处理程序饿死。

目前在 FreeBSD 中的中断线程是指重量级中断线程。 这样称呼它们的原因在于， 转到中断线程需要执行一次完整的上下文切换操作。 在最初的实现中， 内核不允许抢占， 因此中断在打断内核线程之前， 必须等待内核线程阻塞或返回用户态之后才能执行。

为了解决响应时间问题， FreeBSD 内核现在采用了抢占式调度策略。 目前， 只有释放休眠 mutex 或发生中断时才能抢断内核线程， 但最终目标是在 FreeBSD 上实现下面所描述的全抢占式调度策略。

并非所有的中断处理程序都在独立的线程上下文中执行。 相反， 某些处理程序会直接在主中断上下文中执行。 这些中断处理程序， 现在被错误地命名为 “快速” 中断处理程序， 因为早期版本的内核中使用了 INTR_FAST 标志来标记这些处理程序。 目前只有时钟中断和串口 I/O 设备中断采用这一类型。 由于这些处理程序没有独立的上下文， 因而它们都不能获得阻塞性锁， 因此也就只能使用自旋 mutex。

最后， 还有一种称为轻量级上下文切换的优化， 可以在 MD 代码中使用。 因为中断线程都是在内核上下文中执行的， 所以它可以借用任意进程的 vmspace (虚拟内存地址空间)。 因此， 在轻量级上下文切换中， 切换到中断线程并不切换对应的 vmspace， 而是借用被中断线程的 vmspace。 为确保被中断线程的 vmspace 不在中断处理过程中消失， 被中断线程在中断线程不再借用其 vmspace 之前是不允许执行的。 刚才提到的情况可能在中断线程阻塞或完成时发生。 如果中断线程发生阻塞， 则它再次进入可运行状态时将使用自己的上下文， 这样一来， 就可以释放被中断的线程了。

这种优化的坏处在于它们和硬件紧密相关， 而且实现比较复杂， 因此只有在这样做能带来大幅性能改善时才应采用。 目前这样说可能还为时过早， 而且事实上可能会反而导致性能下降， 因为几乎所有的中断处理程序都会立即被全局锁 (Giant) 阻塞， 而这种阻塞将进而需要线程修正。 另外， Mike Smith 提议采用另一种方式来处理中断线程：

在这一模式中适当地采用轻量级上下文切换可能是非常复杂的。 因为我们可能会希望在未来改变这一模式， 因此现在最好的方案， 应该是暂时推迟在轻量级上下文切换之上的工作， 以便进一步完善中断处理架构， 随后再考察轻量级上下文切换是否适用。

简单地说， 线程从一个 CPU 移动到另一个上的过程称作迁移。 在非抢占式内核中， 这只会在明确定义的点， 例如调用 msleep 或返回至用户态时才会发生。 但是， 在抢占式内核中， 中断可能会在任何时候强制抢断， 并导致迁移。 对于 CPU 私有的数据而言这可能会带来一些负面影响， 因为除 curthread 和 curpcb 以外的数据都可能在迁移过程中发生变化。 由于存在潜在的线程迁移， 使得未受保护的 CPU 私有数据访问变得无用。 这就需要在某些代码段禁止迁移， 以获得稳定的 CPU 私有数据。

目前我们采用临界区来避免迁移， 因为它们能够阻止上下文切换。 但是， 这有时可能是一种过于严厉的限制， 因为临界区实际上会阻止当前处理器上的中断线程。 因而， 提供了另一个 API， 用以指示当前进程在被抢断时， 不应迁移到另一 CPU。

这组 API 也叫线程牵制， 它由调度器提供。 这组 API 包括两个函数： sched_pin 和 sched_unpin。 这两个函数用于管理线程私有的计数 td_pinned。 如果嵌套计数大于零， 则线程将被锁住， 而线程开始运行时其嵌套计数为零， 表示处于未牵制状态。 所有的调度器实现中， 都要求保证牵制线程只在它们首次调用 sched_pin 时所在的 CPU 上运行。 由于只有线程自己会写嵌套计数， 而只有其它线程在受牵制线程没有执行， 且持有 sched_lock 锁时才会读嵌套计数， 因此访问 td_pinned 不必上锁。 sched_pin 函数会使嵌套计数递增， 而 sched_unpin 则使其递减。 注意， 这些函数只操作当前线程， 并将其绑定到其执行它时所处的 CPU 上。 要将任意线程绑定到指定的 CPU 上， 则应使用 sched_bind 和 sched_unbind。

内核机制 timeout 允许内核服务注册函数， 以作为 softclock 软件中断的一部分来执行。 事件将基于所希望的时钟嘀嗒的数目进行， 并在大约指定的时间回调用户提供的函数。

未决 timeout (超时) 事件的全局表是由一全局 mutex， callout_lock 保护的； 所有对 timeout 表的访问， 都必须首先拿到这个 mutex。 当 softclock 唤醒时， 它会扫描未决超时表， 并找出应启动的那些。 为避免锁逆序， softclock 线程会在调用所提供的 timeout 回调函数时首先释放 callout_lock mutex。 如果在注册时没有设置 CALLOUT_MPSAFE 标志， 则在调用调出函数之前， 还会抓取全局锁， 并在之后释放。 其后， callout_lock mutex 会在继续处理前再次获得。 softclock 代码在释放这个 mutex 时会非常小心地保持表的一致状态。 如果启用了 DIAGNOSTIC， 则每个函数的执行时间会被记录， 如果超过了某一阈值， 则会产生警告。