Spinlock naming resolved

By Jonathan Corbet
December 9, 2009

The eventual merging of sleeping spinlocks from the realtime tree requires splitting existing locks into two types: those (the majority) which can sleep in a realtime kernel, and those which must remain "real" spinlocks. The 2009 Kernel Summit decided against renaming the vast number of ordinary locks, but did not even attempt to come up with a name for the "raw" spinlock type.

One possibility was raw_spinlock_t, but that name is already used by the lockdep code. After numerous other possible names were considered, the winning suggestion was one by Linus: arch_spinlock_t. This name carries the connotation of a low-level spinlock which is implemented by architecture-specific code; in the absence of a better idea, it has carried the day.

Thomas Gleixner has posted a patch which makes the naming changes. It's worth noting that even though the new type is not a raw_spinlock_t, one still calls raw_spin_lock() to acquire an arch_spinlock_t lock. As of this writing, this patch has not been merged for 2.6.33, but chances are that it will be.

Spinlock naming resolved

Posted Dec 10, 2009 19:27 UTC (Thu) by knobunc (guest, #4678) [Link]

The name also has the implication of an extreme form of a spinlock. Like archenemy and enemy.

Spinlock naming resolved

Posted Dec 17, 2009 22:40 UTC (Thu) by tglx (subscriber, #31301) [Link]

Just for clarification:

We renamed the architecture implementations from raw_spinlock to arch_spinlock. This freed the raw_spinlock name space for the "real" spinlocks.

So the new scheme is:

spinlock - the weakest one, which might sleep in RT

raw_spinlock - spinlock which always spins even on RT

arch_spinlock - the hardware level architecture dependent implementation

We have separate functions for all three types as well, which follow the same name space conventions. spin_*(), raw_spin_*() and arch_spin_*().

With PREEMPT_RT=n (which is current mainline) the spinlock functions map to raw_spinlock functions, but the name space is kept separate even at the variable type level. raw_spin_lock(&spinlock) will result in a warning as well as spin_lock(&raw_spinlock). The warning in mainline is harmless as the data structures are identical, but on RT it's going to fatal.

Thanks,

tglx