Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červenec (YouTube).
Konečně se ochladilo, možná i díky tomu přestaly na chvíli padat rakety jako přezrálé hrušky, díky čemuž se na Virtuální Bastlírně dostane i na jiná, přízemnější témata. Pokud si chcete jako každý měsíc popovídat s dalšími bastlíři, techniky, vědci a profesory u virtuálního pokecu u piva, Virtuální Bastlírna je tu pro Vás.
Ještě před ochlazením se drát na vedení V411 roztáhl o 17 metrů (přesné číslo není známé, ale drát nepřežil) a způsobil tak… více »Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Argentinec, který byl náhodně zachycen Google Street View kamerou, jak se zcela nahý prochází po svém dvorku, vysoudil od internetového giganta odškodné. Soud uznal, že jeho soukromí bylo opravdu porušeno – Google mu má vyplatit v přepočtu asi 12 500 dolarů.
Eben Upton, CEO Raspberry Pi Holdings, informuje o RP2350 A4, RP2354 a nové hackerské výzvě. Nový mikrokontrolér RP2350 A4 řeší chyby, i bezpečnostní, předchozího RP2350 A2. RP2354 je varianta RP2350 s 2 MB paměti. Vyhlášena byla nová hackerská výzva. Vyhrát lze 20 000 dolarů.
Současný vývojový kernel je 4.8-rc5, vydaný 4. září. Linus řekl: „Takže rc5 je výrazně větší než rc4 a minulý týden jsem si dělal naděje, že se vydání zklidní a zmenší, předčasně. (…) Ne, že by něco z toho bylo zvláště znepokojující, ale pokud se odteď věci nezačnou uklidňovat, může jít o jeden z cyklů, které potřebují rc8. Uvidíme.“
Stabilní aktualizace: 4.7.3, 4.4.20 a 3.14.78 byly vydány 7. září. Pozor, prodloužená podpora vydání 3.14 pomalu končí – podle plánu by se mělo dočkat už jen jedné aktualizace.
Existence poptávky po spolupráci na projektu založeném na společném jaderném stromu, který by zároveň obsahoval funkce žádané vývojáři embedded systémů, ukazuje, že ty problémy už sami pociťují.
Zbývá si uvědomit, že už máme takový jaderný strom, kde se všichni (nejen vývojáři embedded systémů) podílejí na vývoji funkcí.
Je to právě upstreamové jádro.
To, co se ti ve skutečnosti povedlo s dodavateli SoC pro Chrome OS, kteří dostali jasnou zprávu, že přítomnost v upstreamu hrála roli při výběru zakázky, bylo to *jediné*, co jsem viděl opravdu zapůsobit na chování celé firmy, nejen několika odhodlaných zaměstnanců. (…)
V okamžiku, kdy lidé od Androidu řeknou, že všechna zařízení Nexus (apod.) poběží na jádře z upstreamu, a vyberou dodavatele SoC, který tomu vyhovuje, pak se začnou dít věci.
Slavný výrok Oscara Wilda praví, že „móda je tak nesnesitelný druh ohavnosti, že ji musíme obměňovat každých šest měsíců.“ Možná, že totéž platí i pro zamykací primitiva v jádře. Základní mechanismy jako mutexy si v průběhu let prošly mnoha různými podobami. Vypadá to, že tuto sezónu jsou mezi trendy vývojáři hitem spárované atomické zámky, takže by nemělo být překvapením, že na scénu přichází nová implementace využívající právě tyto zámky. Možná, že kód se leskne a třpytí, ale také má potenciál výrazně zjednodušit implementaci mutexů.
Mutex je spící zámek, což znamená, že jaderný kód, který se pokusí získat zabraný mutex, může jít spát a čekat, dokud nebude příslušný mutex dostupný. Prvotní implementace mutexů vždy čekatele uspaly, ale vzhledem k aktuálním trendům ve škálovatelnosti mutexy brzy získaly okouzlující příslušenství: optimistický spinning. Probuzení spícího vlákna může trvat dlouhou dobu a jakmile se vlákno rozběhne, může se stát, že cache procesoru již nebude obsahovat žádná jeho data, což povede k výskytu nemoderních cache miss. Namísto toho vlákno se spinem, které čeká na mutex, bude schopné ho rychle dostat a pravděpodobně bude mít data v cache stále k dispozici (cache-hot). Povolení optimistického spinningu může výrazně zlepšit výkon. Cenou je fakt, že mutexy již nejsou férové (mohou být „ukradeny“ z déle čekajícího vlákna), ale být skutečně in není nikdy zadarmo.
Optimistický spinning s sebou přináší zajímavou komplikaci v tom, že vyžaduje sledování současného majitele mutexu. Pokud majitel spí nebo pokud se změní, zatímco vlákno čeká se spinem, nemá další spinning smysl, protože by pravděpodobně trval dlouho. Jako pole v rámci mutexu je však informace o majiteli nejlépe chráněná samotným mutexem. Z principu ale musí být tyto informace přístupné i vláknům, která tento mutex nevlastní. Výsledkem je složitý kód, který se snaží nakládat se zámkem a informací o majiteli současně.
Peter Zijlstra poslal na přehlídku alternativní mechanismus. Vzniklý problém řeší tím, že kombinuje informace o majiteli a statutu zámku do jediného pole uvnitř mutexu. V současných jádrech udržuje pole count (hodnota atomic_t) status zámku samotného, zatímco owner (ukazatel na struct task_struct) naznačuje, které vlákno vlastní mutex. Peterův patch odstraňuje obě tyto pole a nahrazuje je jedinou hodnotou atomic_long_t, nazvanou „owner.“
Tato hodnota má velikost 64 bitů, takže je dost velká na to, aby obsáhla hodnotu ukazatele. Je-li mutex dostupný, neexistuje vlastník, hodnota nového pole owner je nula. Je-li mutex zabrán, dojde k vložení ukazatele na strukturu task_struct daného vlákna, čímž dává najevo jednak nedostupnost mutexu a jednak vlákno, které ho drží. Struktura task_struct musí být vždy řádně zarovnaná, což znamená, že spodní bity ukazatele na ni budou vždy nulové. Tyto bity jsou dostupné pro další využití při zamykání, jak velí současný trend párového zamykání, jejich dvojici si ve stručnosti popíšeme níže.
S novou organizací vypadá kód pro získání mutexu takto:
static inline bool __mutex_trylock(struct mutex *lock) { unsigned long owner, curr = (unsigned long)current; owner = atomic_long_read(&lock->owner); for (;;) { /* must loop, can race against a flag */ unsigned long old; if (__owner_task(owner)) return false; old = atomic_long_cmpxchg_acquire(&lock->owner, owner, curr | __owner_flags(owner)); if (old == owner) return true; owner = old; } }
Makra __owner_task() a __owner_flags() jednoduše maskují příslušné části pole owner. Klíčem je volání atomic_long_cmpxchg_acquire(), které se snaží uložit současné vlákno jako majitele mutexu za předpokladu, že je dostupný. Pokud by ho vlastnilo některé jiné vlákno, toto volání selže a kód mutexu bude vědět, že musí více makat.
Momentálně existují dva příznaky, které je možné uložit do nejméně významných bitů pole owner
. Pokud vlákno zjistí, že musí při čekání na zabraný mutex spát, nastaví MUTEX_FLAG_WAITERS. Vlákno, které mutex aktuálně vlastní, bude vědět, že při uvolnění mutexu musí vzbudit čekající vlákna. Doufá se, že většinou nikdo čekat nebude, udržování tohoto bitu umožňuje vynechat kousek zbytečné práce.
Jak bylo uvedeno výše, optimistický spinning, i když je dobrý pro výkon, není férový. V nejhorším případě by mohlo smolné vlákno soutěžící o vysoce žádaný mutex nadlouho vyhladovět. Zabránit tomu má druhý bit pole owner
, MUTEX_FLAG_HANDOFF, který může změnit způsob, jakým zabraný mutex mění majitele.
Jestliže vlákno už během čekání bylo uspáno, pokusí se získat mutex a selže, může nastavit MUTEX_FLAG_HANDOFF dříve, než se vrátí ke spánku. Když potom dojde k uvolnění mutexu, uvolňující vlákno si všimne příznaku a bude se chovat jinak. Zejména se musí vyhnout vyčištění pole owner
, jak by se stalo za normálních okolností, pro případ, že by jej ukradlo jiné vlákno čekající na mutex. Místo toho najde první vlákno ve frontě na mutex, předá mu vlastnictví přímo a probudí toto vlákno, jakmile je hotovo. Tento tanec vrací trochu férovosti za cenu, že všichni ostatní budou muset počkat, až se spící vlákno probudí a vykoná svou práci.
Nový kód značně zjednodušuje implementaci mutexů tím, že se zbavuje několika podivných případů zahrnujících oddělená pole count
a owner
. Lepší je to v tom, že kód je nově nezávislý na konkrétní architektuře, takže veškerý starý kód mutexů, který závislý na konkrétní architektuře je, se může odstranit. Tím pádem poslední řádek Peterova průvodního dopisu vypadá takto:
49 files changed, 382 insertions(+), 1407 deletions(-)
Odstraňování kódu, jak už to tak bývá, je vždy v módě. A odstraněním 1000 řádků choulostivého zamykacího kódu v jazyce symbolických adres je obzvláště šik. Za předpokladu, že tento kód nepřinese výkonnostní regrese, mohlo by jít o nezbytný doplněk na budoucím plesu začleňovacího okna.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: