DragonFly (the new BSD on the sky) has a new concept for implementing {critical sections}[CriticalSections], called Serializing Tokens.

Before I talk about kernel threads, let me clarify that kernel threads are the same as kernel level threads. A kernel level thread (or kernel thread) does not neccessarily run in privileged mode, but is part of the kernel. Threads running in privileged mode are called kernel-mode threads or better: privileged threads. Privileged mode = protected mode on x86, or supervisor mode on some other architectures like 68k.

Each light-weight kernel thread (LWKT) in DragonFly can hold zero or more serializing tokens. The LWKT scheduler guarantees that a running thread is not preempted by any other thread holding the same serializing token. If a thread blocks or yields (= giving up it’s time-slice), then the LWKT scheduler is allowed to run a thread that has a serializing token in common with the blocking or yielding thread (or one with no token in common). Thus, when a thread blocks or yields, it automatically leaves it’s critical section until it is running again, and it is responsible for all possible harm that may result due to leaving the critical section.

According to Matt Dillon, using serializing tokens, "there are theoretically no unresolvable deadlock situations". But livelocks can happen (in the initial implementation). The following code example demonstrates this (pseudo Ruby-code):

# serializing token T
T = Token.new

# thread A with token T
A = Thread.new(T) {
  loop do
    # neither block, nor yield
  end
}

# thread B with token T
B = Thread.new(T) {
  ...
}

If thread A is started before B, then thread B will never get scheduled to run as long as thread A is running. And in the example above, thread A is running forever.