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 14:00 | Zajímavý článek

    Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).

    Ladislav Hagara | Komentářů: 0
    včera 12:00 | Nová verze

    V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.

    Ladislav Hagara | Komentářů: 0
    17.7. 18:44 | Zajímavý článek

    Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).

    Ladislav Hagara | Komentářů: 1
    17.7. 16:11 | Nová verze

    Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.

    Ladislav Hagara | Komentářů: 2
    17.7. 15:55 | Komunita

    Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.

    Ladislav Hagara | Komentářů: 5
    16.7. 21:22 | IT novinky

    Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.

    Ladislav Hagara | Komentářů: 19
    16.7. 16:22 | IT novinky

    Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.

    Ladislav Hagara | Komentářů: 26
    16.7. 15:33 | Upozornění

    Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapyAI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.

    bindiff | Komentářů: 8
    16.7. 13:33 | Bezpečnostní upozornění

    Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).

    Ladislav Hagara | Komentářů: 5
    16.7. 00:11 | Nová verze

    Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.

    Ladislav Hagara | Komentářů: 0
    Jaký je váš oblíbený skriptovací jazyk?
     (59%)
     (27%)
     (7%)
     (3%)
     (0%)
     (1%)
     (4%)
    Celkem 410 hlasů
     Komentářů: 16, poslední 8.6. 21:05
    Rozcestník

    Administrace komentářů

    Jste na stránce určené pro řešení chyb a problémů týkajících se diskusí a komentářů. Můžete zde našim administrátorům reportovat špatně zařazenou či duplicitní diskusi, vulgární či osočující příspěvek a podobně. Děkujeme vám za vaši pomoc, více očí více vidí, společně můžeme udržet vysokou kvalitu AbcLinuxu.cz.

    Příspěvek
    23.2.2009 10:38 frr | skóre: 34
    Rozbalit Rozbalit vše Re: C a pthreads - cekani na vice conditional variables

    Za prvé si všimněte (přečtěte si dokumentaci), že při práci s "conditional variable" je potřeba ještě vedle této proměnné taky Mutex. Ten je tam právě proto, aby bylo možné nejenom signalizovat "něco někde se stalo", ale aby čekající vlákno mělo šanci si taky atomicky ověřit z dalších datových struktur, *co* se vlastně stalo. Volání pthread_cond_wait() se ukládá ke spánku a zároveň atomicky odemyká mutex, aby se jím mohla chránit další vlákna.

    Souhlasím, že je třeba použít jedinou podmínkovou proměnnou, kterou může polechtat kterýkoli z workerů. A potažmo jediný doprovodný mutex.

    Takže workeři budou mít každý nějaký svůj kus dat, který bude za provozu chráněný tímto "společným doprovodným mutexem podmínkové proměnné".

    Worker:

    pthread_mutex_lock(&mutex);
    Worker_Save_Message_To_Boss(); // toto nemusi byt funkce - proste kus kodu
    pthread_mutex_unlock(&mutex);
    pthread_cond_signal(&boss_cond);
       (... možná že ta poslední dvě volání lze navzájem prohodit... )

    Boss:

    pthread_mutex_lock(&mutex);
    pthread_cond_wait(&boss_cond,&mutex);
    Boss_Check_Messages_From_All_Workers(); // toto nemusi byt funkce - proste kus kodu
    pthread_mutex_unlock(&mutex);

    Jakým konkrétně způsobem budou workeři říkat bossovi, co se přesně stalo, to je čistě na uvážení programátora. Může mít třeba každý worker svůj řádek v nějaké tabulce (poli), ve kterém může signalizovat, že "já něco potřebuju". A mutexem je chráněna manipulace s tabulkou.  Nebo libovolně složitější struktura, třeba nějaký dynamický index per-worker objektů, které mohou být v C++ třeba polymorfní. Nebo může komunikační roli plnit fronta zpráv, jak už jste naznačil - což je mimochodem možná optimální řešení co do nároků na čas procesoru, protože není třeba vyčerpávajícím způsobem kontrolovat všechny workery.

    Zajímavým a odděleným problémem pak je, kdo může přidávat/odebírat záznamy v indexu workerů - zda boss, nebo workeři, nebo kdo vlastně, a jak to přesně zařídit, aby nedocházelo k přístupu do objektů, které již byly dealokovány/destruovány... (v případě ukončení workerů). Jistě je možné pojmout to nejjednodušším možným způsobem na úrovni základních operací s POSIXovými vlákny (pthread_join() a spol). 
    Upozorňuji taky na možnost vykašlat se na pthread_join(), plodit workery jako "detached" a při ukončení celého programu prostě rozeslat dohodnutý signál a počkat, až workeři sami pochcípou^W^W^W odejdou na svačinu (počítat si někde, kolik je jich naživu, a počkat, až jejich celkový počet klesne na nulu).

    Pro svižný chod vícevláknového programu je potřeba, aby se v tom "podmínkovém doprovodném mutexu" žádný worker ani boss dlouho nezamysleli - konkrétně aby se nemohlo stát, že se někdo zablokuje v syscallu. V kritické sekci je potřeba řešit jenom opravdu nezbytné věci. Pokud je potřeba řešit něco s rizikem "zamyšlení se", je potřeba si tuto práci odložit na dobu po uvolnění mutexu (třeba odstranit objekt z indexu a podržet pointer přes pomocnou lokální proměnnou). Práce s dynamickými datovými strukturami by měla být ještě zhruba OK - paměťové alokace/dealokace nejsou až tak rizikové (záleží na požadované době odezvy aplikace).

    Předávání dat workerům řeším typicky tak, že pro každé vlákno vytvářím instanci nějakého objektu, který pro toto vlákno drží pohromadě všechna relevantní data. Pokud jsou workeři různých typů, tak ten objekt může být polymorfní. Boss vytvoří instanci objektu, přidá ho do nějakého svého globálního indexu, nastartuje workera, kterému předá odkaz na objekt argumentem void* skrz funkci pthread_create() - od toho tam ten argument je. V tu chvíli (v okamžiku startu vlákna) vzniká zajímavý dílčí problém typu "vejce a slepice" - thread ID vznikne teprve ve chvíli, kdy je worker úspěšně nastartován, Boss se ho dozví teprve po návratu funkce pthread_create() - v tu chvíli už se Worker možná rozběhl a někam kus utekl, aniž by v globálním indexu bylo poznamenáno jeho thread ID. Obecně není možno předvídat, zda se po pthread_create() vzbudí dřív Boss nebo zrovna narozený Worker. Proto je vhodné tuto počáteční inicializaci ošetřit opět mutexem. Tato kritická sekce při startu workera je věcně oddělený problém od výše zmíněné "komunikační" podmínkové proměnné a jejího doprovodného mutexu - proto typicky používám pro start workerů oddělený mutex.

     Boss:

    tmp_worker = new Worker_obj();
    pthread_mutex_lock(&thr_start_mutex);
    tmp_worker->ID = pthread_create(..., (void*)tmp_worker);
    add_worker_to_index(tmp_worker);
    pthread_mutex_unlock(&thr_start_mutex);

    Worker:

    worker_thr(...)
    {
       pthread_mutex_lock(&thr_start_mutex);
       pthread_mutex_unlock(&thr_start_mutex);
       ...
    }

    Globální index workerů může být třeba map<pthread_t, Worker_obj*>. Takových indexů může být víc. Čímž se dostáváme také k zajímavým zádrhelům v oblasti konstrukce C++ map<> šablon obsahujících pointery v roli cílů i klíčů (pokud je pthread_t nebo jiný porovnávací identifikátor memberem Worker_obj) - dají se použít obalové objektíky, overloadnutý operator<(), náhrada porovnávacího functoru apod...
    Teď mě napadl domácí úkol: zkuste se zamyslet, jak by bylo potřeba upravit Bosse, pokud by se funkce add_worker_to_index() volala z konstruktoru Worker_obj - potažmo konstruktor Worker_obj by měl jako povinný argument "pthread_t ID" :-) Vlastně by ta mapa mohla být statickou member proměnnou Worker_obj...
    Jojo - je to už delší doba, co jsem si na to naposledy sáhl :->

    Ještě jednu poznámku k tomu: když už máme datový objekt, který odpovídá konkrétnímu běžícímu posixovému vláknu, proč to nezařídit tak, aby vlákno bylo member metodou? Aby si mohlo šahat přímo do member proměnných svého objektu přes implicitní "this."... Tedy proč ne: protože posixová funkce pthread_create() je určena pro holé Cčko, a není si vědoma nějakého "this". "Datový vozík vlákna" se dá předat jedině skrz "void* data" poslední argument. Ale je tu samozřejmý způsob, jak tuto "neschopnost" pthred_create() obejít: nadefinovat jednoduchou obalovou funkci (možno jako statickou metodu), která se spustí skrz pthread_create() a jediné co udělá je, že spustí "výkonná střeva", deklarovaná již v podobě klasické member metody. Tj.

    // static
    void* Worker_obj::worker_thr(void* data)
    {
        return ((Worker_obj*)data)->do_the_job();
    }

    Potažmo u polymorfních workerů se nabízí, aby Boss měl jenom jednu spouštěcí smyčku a rozlišení podtypů workerů se dělo různými variantami virtuální metody do_the_job()...

    Jasně, pro použití posixových vláken jsou v C++ hotové knihovny... ale to je nuda, ne? :-)

    [:wq]

    V tomto formuláři můžete formulovat svou stížnost ohledně příspěvku. Nejprve vyberte typ akce, kterou navrhujete provést s diskusí či příspěvkem. Potom do textového pole napište důvody, proč by měli admini provést vaši žádost, problém nemusí být patrný na první pohled. Odkaz na příspěvek bude přidán automaticky.

    Vaše jméno
    Váš email
    Typ požadavku
    Slovní popis
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.