Vlákno názorů k článku
Linus Torvalds odpovídá na kritiku plánovače jádra od Naith - Zdravím, proč vlastně nemám použít spinloock v user...

Zdravím, proč vlastně nemám použít spinloock v user space? Pokud jsem to správně pochopil, tak to slouží k zamezení provádění toho samého kódu paralelně ve více vláknech. Asi se to dá možná obejít přes semafory, ale obávám se že nezajistim atomicitu. Je tedy jiná možnost, jak toho docílit?

Přirozenou alternativou je mutex, což je vlastně speciální případ semaforu.

V těch komentářích jsou důvody vysvětlené a to podstatné si vlastně uvědomuje i autor původního článku, jen se z nějakých důvodů rozhodl ignorovat to a svalovat vinu na někoho jiného. Spinlock se hodí pro nasazení, kde se obvykle nečeká vůbec a když ano, tak jen velmi krátce (celou dobu, co čekám, se točím ve smyčce, takže příslušný procesor běží naplno přestože nedělá nic užitečného). Hlavní výhodou je nízká latence (odpadá režie přepnutí na jiný task a zpátky) a to, že se dá spinlock použít i v atomickém kontextu, kdy task spát nemůže (to se týká použití v jádře).

V userspace se mi může stát, že mne jádro tak jako tak uspí (a proces má jen velmi malou možnost ovlivnit, jestli a kdy se tak stane), čímž celá ta výhoda padá a zůstanou v podstatě jen nevýhody. To je vidět i na tom benchmarku z původního článku: autor si poznamená čas "těsně před" odemčením zámku a "těsně po" jeho uzamčení jiným procesem - jenže si neuvědomuje, že i když to "těsně před/po" znamená hned předcházející nebo následující řádek zdrojáku, pořád se může stát, že se mezitím daný proces odscheduluje, čímž vznikne ta obrovská prodleva, kterou autor připisuje (podle něj) neefektivnímu scheduleru.

Žádné pravidlo samozřejmě neplatí stoprocentně a určitě by se našly případy, kdy by mělo smysl použít spinlock i v userspace. Ale budou to spíš výjimky a bude to chtít moc dobře vědět, co člověk dělá a proč.