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í
×

dnes 14:44 | Komunita

Mozilla.cz informuje, že Firefox bude možná upozorňovat na úniky vašich hesel. V Mozille prototypují upozorňování na únik informací o vašem účtu, pokud se na seznamu Have I been pwned? objeví služba, ke které máte ve Firefoxu uložené přihlašovací údaje. Informace se objevila v pravidelném newsletteru o vývoji Firefoxu.

Ladislav Hagara | Komentářů: 0
dnes 00:22 | Bezpečnostní upozornění

Společnost ZONER informuje o bezpečnostním incidentu, při kterém došlo ke zcizení a zveřejnění části přihlašovacích údajů zákazníků k elektronické poště a webhostingu CZECHIA.COM.

Ladislav Hagara | Komentářů: 0
včera 23:44 | Nová verze

Byla vydána nová stabilní verze 1.13 (1.13.1008.32) webového prohlížeče Vivaldi (Wikipedie). Z novinek vývojáři zdůrazňují možnost zobrazení otevřených i uzavřených listů pomocí ikonky Okno na postranní liště a vylepšené stahování (YouTube). Nejnovější Vivaldi je postaveno na Chromiu 62.0.3202.97.

Ladislav Hagara | Komentářů: 8
včera 20:55 | Nová verze

Byla vydána verze 2017.3 dnes již průběžně aktualizované linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux. Aktualizovat systém lze pomocí příkazů "apt update; apt dist-upgrade; reboot". Z novinek lze zmínit 4 nové nástroje: InSpy, CherryTree, Sublist3r a OSRFramework.

Ladislav Hagara | Komentářů: 1
včera 01:55 | Bezpečnostní upozornění

Společnost Uber potvrdila bezpečnostní incident a únik dat v roce 2016. Unikly údaje o 57 milionech cestujících (jména, emailové adresy a čísla mobilních telefonů) a 600 tisících řidičích (navíc čísla řidičských průkazů).

Ladislav Hagara | Komentářů: 1
21.11. 23:44 | Humor

Co vypíše příkaz man půl hodiny po půlnoci? Text "gimme gimme gimme". Jedná se o virtuální velikonoční vajíčko připomínající skupinu ABBA a její hit Gimme! Gimme! Gimme! (A Man After Midnight). Problém nastane, pokud gimme gimme gimme nabourá automatizované testování softwaru. To se pak příkaz man musí opravit [Bug 1515352] [reddit].

Ladislav Hagara | Komentářů: 10
21.11. 18:11 | Zajímavý článek

Mozilla.cz informuje, že Firefox na Fedoře podporuje Client Side Decorations. Firefox na Linuxu se vykresluje včetně standardního záhlaví okna, které je v případě webového prohlížeče většinou nadbytečné a ubírá drahocenné vertikální místo na obrazovce. Verze distribuovaná uživatelům Fedory však nyní obsahuje experimentální podporu pro takzvané Client Side Decorations, které umožňují vykreslování „oušek“ panelů do záhlaví okna.

Ladislav Hagara | Komentářů: 12
21.11. 05:00 | Bezpečnostní upozornění

Maxim Goryachy a Mark Ermolov ze společnosti Positive Technologies budou mít v prosinci na konferenci Black Hat Europe 2017 přednášku s názvem "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". O nalezeném bezpečnostním problému informovali společnost Intel. Ta bezpečnostní problém INTEL-SA-00086 v Intel Management Engine (ME), Intel Server Platform Services (SPS) a Intel

… více »
Ladislav Hagara | Komentářů: 43
21.11. 01:33 | Zajímavý projekt

Na Humble Bundle byla spuštěna akce Humble Book Bundle: Java. Za 1 dolar a více lze koupit 5 elektronických knih, za 8 dolarů a více 10 elektronických knih a za 15 dolarů a více 15 elektronických knih věnovaných programovacímu jazyku Java od nakladatelství O'Reilly. Peníze lze libovolně rozdělit mezi nakladatelství O'Reilly, neziskovou organizaci Code for America a Humble Bundle.

Ladislav Hagara | Komentářů: 0
21.11. 00:11 | Zajímavý projekt

Článek na OMG! Ubuntu! představuje rodinu písma IBM Plex. Jedná se o open source písmo (GitHub) navržené a uvolněné společností IBM (YouTube, Carbon Design System). Ukázka na Font Squirrel.

Ladislav Hagara | Komentářů: 14
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 753 hlasů
 Komentářů: 37, poslední 21.11. 15:21
    Rozcestník

    OctaSTD - bezpečný a rychlý multithreading a další změny

    23.3. 18:05 | Přečteno: 1224× | octaforge | Výběrový blog

    Poslední zápisek byl celkem nedávno, ale od té doby se událo celkem dost změn, hlavně co se týče připravovaného paralelního frameworku, který umožní využití vícejádrových CPU bez obvyklých problémů spojených s vlákny a jejich synchronizací.

    Ale první na chvíli zpět ke korutinám.

    Změny v korutinách

    Díky tomu, že korutiny jsou víceméně lehké vlákna, ale s kooperativním schedulingem, je můžeme jednoduše využít jako základ pro lehké vlákna s vlastním schedulerem. Ale aby to opravdu fungovalo a bylo optimální, potřebujeme pár věcí.

    Stack alokátory

    Korutiny si alokují vlastní stacky. Jednou strategií je prostě dát korutině velikost stacku a potom udělat alokaci uvnitř. To ale není flexibilní, takže OctaSTD má podporu pro stack alokátory.

    Stack alokátor vypadá stukturálně nějak takto, podobně jako v Boost.Context:

    
    struct stack_allocator {
        stack_context allocate();
        void deallocate(stack_context &) noexcept;
    };
    

    Velikost stacku si určí alokátor, může to být třeba argument při konstrukci alokátoru. V OctaSTD jsou dva výchozí stack alokátory. Jeden je fixedsize_stack, ten druhý protected_fixedsize_stack. Jak jejich název napovídá, alokují stacky s fixní velikostí. Implementačně používají mmap() s MAP_ANON na POSIX systémech a VirtualAlloc na Windows. Jejich velikost je v OctaSTD vždy násobek velioksti jedné stránky (jedná stránka je na x86 4 KiB).

    Hranice velikosti a výchozí velikost jsou dány strukturou stack_traits. Ta poskytuje několik funkcí, které alokátoru řeknou, zda je velikost stacku nějak omezená systémem, jaké jsou limity a jaká je výchozí velikost. Výchozí velikost stacku je na běžných architekturách 64 KiB.

    Protected stack je v podstatě to samé; jediný rozdíl je, že jedna stránka na konci stacku je chráněná paměť, takže místo stack overflow dostaneme při přetečení předvídatelně segfault.

    Stack pool

    Pokud implementujeme lehké vlákna a scheduler, bude jich možná i hodně, a alokovat pro každou korutinu nový stack zvlášť není optimální. Proto má OctaSTD stack pool. Ten dělá dvě věci:

    Stack pool má metodu get_allocator(), která vrátí stack allocator alokující ze stack poolu.

    Rostoucí stacky

    Chtěl jsem implementovat i rostoucí stacky, tzn. takové, které budou postupně rezervovat více místa jak je potřeba. To se dá implementovat pomocí víceméně nezdokumentovaných API z libgcc pro GCC a Clang na POSIX systémech, a pak se musí kompilovat s -fsplit-stack. Bohužel toto není možné na Windows a na ostatních kompilátorech. Proto jsem se rozhodl rostoucí stacky neimplementovat - pokud je nemůžu garantovat na všech platformách, je lepší je nemít vůbec. Výchozí velikost pevného stacku by měla ale měla skoro vždy stačit.

    Generátory

    Standardní korutiny nejsou optimální jako generátory. Proto jsem přidal nový typ pro generátory. Rozdíly jsou v podstatě takové:

    S generátory se dá psát třeba takový kód:

    
    auto f = [](auto yield) {
        for (int i: range(5, 26, 5)) {
            yield(i);
        }
    };
    for (int i: generator<int>{f}) {
        writefln("generated: %s", i);
    }
    

    Channels

    OctaSTD teď implementuje tzv. channels, podobné jako třeba v jazyce Go. Pro ty, co je neznají, je to v podstatě thread-safe queue. V OctaSTD mají channels momentálně takový interface:

    
    template<typename T>
    struct channel {
        void put(T const &);
        void put(T &&);
        T get();
        bool try_get(T &);
        bool is_closed();
        void close();
    };
    

    Funguje to tak, že metoda .put(x) vloží do fronty hodnotu a probudí jedno vlákno, které na hodnotu čeká. Metoda .get() oproti tomu zkontroluje, jestli je ve frontě už nějaká hodnota; pokud ano, tak si ji to vezme, pokud ne, tak pozastaví vlákno a čeká na .put(x). Jeden channel může být sdílený mezi několika vlákny (třeba několik vláken může na něm volat .put(x) a jedno vlákno několikrát .get() nebo i obráceně). Komunikace může probíhat oběma směry, ale vzhledem k tomu, že jde o jednu frontu, tak většinou dává smysl jeden vybraný směr.

    Metoda .try_get(x) je rozdílná jen v tom, že na hodnotu nečeká a vrátí true v případě přítomnosti hodnoty ve frontě a false v případě její nepřítomnosti. A .is_closed() a .close() je celkem jasné. Po zavření kanálu jej není možné dále použít.

    Interní stav v channels používá reference counting. Díky tomu každé vlákno může mít vlastní referenci na channel a interní stav se neuvolní, dokud je alespoň jedno z vláken naživu. To dělá channels bezpečné, i s nepředvídatelným schedulerem.

    Concurrency

    Na základě korutin a kanálů implementuje OctaSTD svůj systém.

    Schedulery

    Základní strukturou je v tomto případě scheduler. To je struktura, která definuje chování úloh a s nimi spojených operací. Použití je u všech schedulerů stejné. Mají tento základní interface:

    
    struct scheduler {
        template<typename F, typename ...A>
        auto start(F &&func, A &&..args) -> std::result_of_t<F(A...)>;
        void spawn(std::function<void()>);
        void yield();
        generic_condvar make_condition();
    };
    

    První je metoda .start(f, a...). Ta v podstatě obvykle nahrazuje standardní main. Je první úlohou, kterou scheduler spustí (ta má také daleko větší stack, protože 64 KiB by prostě pro celý program nestačilo). Tato metoda vrací návratovou hodnotu z předané funkce, a neudělá to, dokud všechny úlohy neskončí.

    Následuje metoda .spawn(f). Ta spustí novou úlohu (vlákno). Co to vlastně ta úloha je si definuje sám scheduler.

    Dále je .yield(). Ta řekne scheduleru, že se má aktuálně běžící úloha pozastavit a přesunout na konec fronty. To způsobí spuštění další úlohy ve frontě s tím, že ta předchozí bude pokračovat později.

    A pak tu máme .make_condition(). Struktura generic_condvar je polymorfický wrapper pro buď normální std::condition_variable nebo vlastní interní strukturu, kterou si definuje sám scheduler. Poskytuje vlastně obecný interface k 1) pozastavení aktuální úlohy a čekání 2) probuzení jedné čekající úlohy 3) probuzení všech čekajících úloh. Jak to udělá, už je na implementaci, a záleží na tom, jak je definována úloha.

    Takže to funguje v podstatě tak, že "hlavní" stupní funkce se spustí přes .start(f, a...) a ta pak dále spouští další úlohy.

    Dostupné schedulery

    thread_scheduler

    Prvním dostupným schedulerem je thread_scheduler. Ten reprezentuje každou úlohu systémovým vláknem (std::thread) a samotný scheduling nechá na operačním systému. Jako generic_condvar používá std::condition_variable. Na určitých systémech (Windows) je tento přístup relativně pomalý a náročný. Na Linuxu a BSD jsou vlákna vcelku lehká, ale stále pomalejší než korutiny. Efektivně tento scheduler implementuje model 1:1 (kernel level scheduling).

    simple_coroutine_scheduler

    Další jednoduchý scheduler, který pro změnu implementuje model N:1 (user-level scheduling), kde každá úloha běží na hlavním systémovém vlákně a je reprezentována korutinou. Jako podmínková proměnná je použita jednoduchá vlastní implementace s jedním boolem a pár yieldy. Tento scheduler je velmi lehký, ale omezený na jedno vlákno.

    coroutine_scheduler

    Třetí, nejdůležitější scheduler implementuje hybridní M:N model, kde se spustí určitý počet systémových vláken (typicky stejný, jako počet fyzických vláken na CPU) a jednotlivé úlohy se reprezentují korutinami. Tento přístup kombinuje to nejlepší z těch dvou ostatních - máme velmi lehké úlohy, kterých můžeme tvořit stovky, a ty se rovnoměrně pospouští na jednotlivých systémových vláknech. Jako podmínková proměnná je použita trochu složitější vlastní implementace s čekací frontou.

    Dostupné API

    Pro pohodlí OctaSTD definuje několik API, které se nemusí explicitně volat na aktuálním scheduleru, protože znají aktuální scheduler interně.

    
    template<typename F, typename ...A>
    void spawn(F &&func, A &&...args);
    
    template<typename T>
    channel<T> make_channel();
    
    void yield();
    

    První API, spawn(f, ...) spustí na aktuálním scheduleru novou úlohu. Druhé API, make_channel<T> vytvoří komunikační kanál s typem T. A třetí API, yield() prostě zavolá stejné API na scheduleru.

    Použití

    Tady je ukázka z příkladů v OctaSTD repozitáři:

    
    #include <ostd/io.hh>
    #include <ostd/concurrency.hh>
    
    using namespace ostd;
    
    int main() {
        /* have an array, split it in two halves and sum each half in a separate
         * task, which may or may not run in parallel with the other one depending
         * on the scheduler currently in use - several schedulers are shown
         */
        auto foo = []() {
            auto arr = ostd::iter({ 150, 38, 76, 25, 67, 18, -15,  215, 25, -10 });
    
            auto c = make_channel<int>();
            auto f = [](auto c, auto half) {
                c.put(foldl(half, 0));
            };
            spawn(f, c, arr.slice(0, arr.size() / 2));
            spawn(f, c, arr + (arr.size() / 2));
    
            int a = c.get();
            int b = c.get();
            writefln("%s + %s = %s", a, b, a + b);
        };
    
        /* using thread_scheduler results in an OS thread spawned per task,
         * implementing a 1:1 (kernel-level) scheduling - very expensive on
         * Windows, less expensive on Unix-likes (but more than coroutines)
         */
        thread_scheduler{}.start([&foo]() {
            writeln("(1) 1:1 scheduler: starting...");
            foo();
            writeln("(1) 1:1 scheduler: finishing...");
        });
        writeln();
    
        /* using simple_coroutine_scheduler results in a coroutine spawned
         * per task, implementing N:1 (user-level) scheduling - very cheap
         * and portable everywhere but obviously limited to only one thread
         */
        simple_coroutine_scheduler{}.start([&foo]() {
            writeln("(2) N:1 scheduler: starting...");
            foo();
            writeln("(2) N:1 scheduler: finishing...");
        });
        writeln();
    
        /* using coroutine_scheduler results in a coroutine spawned per
         * task, but mapped onto a certain number of OS threads, implementing
         * a hybrid M:N approach - this benefits from multicore systems and
         * also is relatively cheap (you can create a big number of tasks)
         */
        coroutine_scheduler{}.start([&foo]() {
            writeln("(3) M:N scheduler: starting...");
            foo();
            writeln("(3) M:N scheduler: finishing...");
        });
    }
    
    /*
    (1) 1:1 scheduler: starting...
    356 + 233 = 589
    (1) 1:1 scheduler: finishing...
    
    (2) N:1 scheduler: starting...
    356 + 233 = 589
    (2) N:1 scheduler: finishing...
    
    (3) M:N scheduler: starting...
    356 + 233 = 589
    (3) M:N scheduler: finishing...
    */
    

    Závěr

    To je zatím všechno. Tyto API jsou všechny momentálně dost jednoduché a budou se rozšiřovat podle potřeby. To bude potom tématem dalšího zápisku.

           

    Hodnocení: 100 %

            špatnédobré        

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

    Komentáře

    Vložit další komentář

    28.3. 21:39 citanus | skóre: 10 | Cork (Ireland)
    Rozbalit Rozbalit vše Re: OctaSTD - bezpečný a rychlý multithreading a další změny

    pekna prace

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