I’ve been reading a book on Linux’s networking internals and it occurs to me that it’s not always necessary to use concurrency semantics to maintain shared state. So long as the stateful element is naturally atomic and has only one writer globally in the program, it’s safe to use it without concurrency semantics. One example that I’m thinking of is in the Linux kernal’s time management functions. The variable
jiffies is globally available in the kernel which measures the number of ticks since the system booted. 1
jiffies is only changed in one place, the internal timekeeping code, but it can be read by any part of the system. Because
jiffies is a single numerical value, operations on it are atomic so it’s impossible to read it in an inconsistent state and because it is only written to by one part of the application, race conditions are also a non-issue. So locks, STM and other forms of concurrency semantic are unnecessary in this instance. I suspect that this could apply to any global counter.
- The length of a tick is architecture dependent. ↩