abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 16:11 | Nová verze

Byla vydána verze 8.0 open source unixového operačního systému NetBSD (Wikipedie). Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 12:33 | Zajímavý projekt

Uživatel denholmsdead již více než rok zveřejňuje na redditu své obrázky s linuxovou tématikou. Náhledy obrázků jsou k dispozici na linux.pictures. Obrázky v plném rozlišení na GitLabu.

Ladislav Hagara | Komentářů: 1
20.7. 18:55 | Zajímavý projekt

Společnosti Google, Microsoft, Twitter a Facebook společně představily open source platformu Data Transfer Project (DTP). Cílem platformy je zjednodušit uživatelům přechod a přenos dat mezi jednotlivými online službami. Podrobnosti v pdf a na GitHubu.

Ladislav Hagara | Komentářů: 4
20.7. 18:33 | Nová verze

Canonical a Microsoft společně oznámili, že PowerShell Core je nově dostupný také jako snap balíček na Snapcraftu. Microsoft uvolnil zdrojové kódy PowerShellu (Wikipedie, GitHub) v srpnu 2016 pod open source licencí MIT a naportoval je na Linux.

Ladislav Hagara | Komentářů: 2
20.7. 13:11 | Zajímavý projekt

Novinkou v minor aktualizaci webového prohlížeče Vivaldi je podpora vyhledávače Qwant (Wikipedie). Vývojáři Vivaldi zdůrazňují, že se jedná o evropský vyhledávač respektující soukromí uživatelů.

Ladislav Hagara | Komentářů: 7
20.7. 01:33 | Nová verze

Po šesti letech od vydání verze 1.0 byla vydána verze 2.0 multiplatformního editoru tagů MusicBrainz Picard (Wikipedie). Přehled novinek, vylepšení a oprav v changelogu.

Ladislav Hagara | Komentářů: 0
19.7. 16:22 | Nová verze Ladislav Hagara | Komentářů: 14
19.7. 15:00 | Komunita

Dnes končí podpora Ubuntu 17.10 Artful Aardvark. Uživatelům je doporučen přechod na Ubuntu 18.04 Bionic Beaver s prodlouženou podporou do roku 2023. Podpora standardních verzí Ubuntu je 9 měsíců. Verze 17.10 byla vydána 19. října 2017.

Ladislav Hagara | Komentářů: 12
19.7. 13:33 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 334 bezpečnostních chyb. V Oracle Java SE je například opraveno 8 bezpečnostních chyb. Všechny jsou vzdáleně zneužitelné bez autentizace. V Oracle MySQL je opraveno 31 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 7 z nich.

Ladislav Hagara | Komentářů: 0
19.7. 13:11 | Zajímavý software

Nick Clifton zveřejnil na blogu společnosti Red Hat věnujícímu se počítačové bezpečnosti nástroj, pomocí kterého lze ověřit, zda jsou binární spustitelné soubory odolné vůči variantě 1 bezpečnostní chyby Spectre v procesorech.

Ladislav Hagara | Komentářů: 0
Jak čtete delší texty z webových stránek?
 (77%)
 (20%)
 (5%)
 (7%)
 (2%)
 (10%)
Celkem 376 hlasů
 Komentářů: 40, poslední 29.6. 10:21
    Rozcestník

    Jaderné noviny - 9. 9. 2016: Reimplementace mutexů spárovanými zámky

    18. 9. 2016 | Redakce | Jaderné noviny | 1607×

    Stav vydání jádra. Citáty týdne: Rik van Riel a Linus Walleij. Reimplementace mutexů spárovanými zámky.

    Stav vydání jádra

    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.

    Citáty týdne

    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.

    -Rik van Riel

    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.

    -Linus Walleij

    Reimplementace mutexů spárovanými zámky

    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.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.