Myslím, že velmi dobrou tradicí linuxového jádra je nepřidávat do něj jednoúčelové věci či věci sloužící jen jedné konkrétní aplikaci - a na místo toho vymyslet nějaký obecnější mechanismus, kterým se požadovaná věc dá implementovat, ale možná ještě spousta dalších.
Krásným příkladem budiž snaha dostat do jádra kontejnery, ze kterých se nakonec vyklubaly namespaces, které jsou užitečné i na mnoho jiných věcí (aplikační sandboxy, emulace síťových topologií a mnoho dalšího).
Jiný příklad byl třeba ashmem z Androidu (potřebný pro běh emulačních vrstev typu Waydroid - tedy podobný případ jako tady u wine). Nakonec byla místo slepého přijetí této jednoúčelové věci přidána potřebná funkcionalita to memfd, což je daleko obecnější mechanismus, a Android userspace se to naučil používat.
Doufám, že i v tomto případě to dopadne podobně.
Takže podpora Android aplikací není jednoúčelová a Windows aplikací je? Myslíte, že ten memfd bude třeba za 5 let používat aspoň jedna další aplikace? V jádře je mraky různých typů synchronizací, není žádná "ta jediná správná pro Linux". V monolitickém jádru to jinak udělat nejde. Aspoň že je to jako driver modul, tj. kód se vám nemusí zavádět, dokud si neřeknete.
Zrovna ta synchronizace ve Windows, pokud by byla implementována rozumně uceleně, je obecná dost. WaitForMultipleObjects a její příbuzné jsou skvělé obecné funkce, protože (ve Windows) do nich můžete strčit cokoliv, co disponuje signálním stavem (event, mutex, process, thread, file/pipe/socket, semaphore, ...).
U linuxového jádra mě vždy z povzdálí bavilo sledovat právě tyhle experimenty s implementacemi nových primitiv. U Windows byla adopce vzhledem k politice zpětné kompatibility vždy o dost pomalejší, pokud vůbec proběhla :-).
Co se týče futexu, je fakt, že nějaký +- ekvivalent asi přišel s Vista (2006) a jejich condition variables a SRWLs (pointer-sized RW zámky, co se také snaží vše řešit v usermodu, dokud to jen jde -- v jádře se v podstatě to samé jmenuje pushlock a je to tam již od XP). Z hlediska snahy volat jádro pouze v případě nutnosti tam již dříve byly tzv. kritické sekce (v jádře tzv. executive resources), ale to jsou dost těžkotonážní obludy.