As kernels manage hardware, in certain cases the only way to prevent race conditions in kernel code is to disable interrupts. This is a kernel way of granting code exclusive access to resources at lowest levels.

In the realm of embedded devices, it is often not feasible to keep interrupts disabled for prolonged period of time. This affects the design of portions of the kernel which modify data structures accessible from within interrupt context. Despite very limited API offered by the kernel to interrupt handlers, this still affects key data structures in kernel - scheduler table and notification table. This in turn means that any use of threading or notification API would require interrupts to be disabled for potentially prolonged time periods.

To avoid prolonged periods of disabled interrupts we went for some inspiration into the land of lock-free and wait-free programming. We took basic primitives used in lock-free programming and modified them to avoid excessive overhead such primitives have. The resulting mechanism is not lock-free anymore yet offers semantics which allows us to lock (disable interrupts) for much shorter and well predictable periods of time.

The resulting mechanism resembles database transactions to certain extent. This talk will provide introduction to the transaction subsystem, reason on why it offers benefits over raw locks and elaborate on the topic "How not to loose your hair while trying to work with ever-changing data consistently".