I’ve been read­ing a book on Lin­ux’s net­work­ing inter­nals and it occurs to me that it’s not always nec­es­sary to use con­cur­rency seman­tics to main­tain shared state. So long as the state­ful ele­ment is nat­u­rally atomic and has only one writer glob­ally in the pro­gram, it’s safe to use it with­out con­cur­rency seman­tics. One exam­ple that I’m think­ing of is in the Linux ker­nal’s time man­age­ment func­tions. The vari­able jiffies is glob­ally avail­able in the ker­nel which mea­sures the num­ber of ticks since the sys­tem boot­ed. ¹ jiffies is only changed in one place, the inter­nal time­keep­ing code, but it can be read by any part of the sys­tem. Because jiffies is a sin­gle numer­i­cal val­ue, oper­a­tions on it are atomic so it’s impos­si­ble to read it in an incon­sis­tent state and because it is only writ­ten to by one part of the appli­ca­tion, race con­di­tions are also a non-is­sue. So locks, STM and other forms of con­cur­rency seman­tic are unnec­es­sary in this instance. I sus­pect that this could apply to any global coun­ter.

1. The length of a tick is architecture dependent. ↩