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 15:33 | Nová verze

    Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.8.

    Ladislav Hagara | Komentářů: 2
    dnes 14:22 | IT novinky

    Herní studio Hangar 13 vydalo novou Mafii. Mafia: Domovina je zasazena do krutého sicilského podsvětí na začátku 20. století. Na ProtonDB je zatím bez záznamu.

    Ladislav Hagara | Komentářů: 0
    dnes 13:22 | IT novinky

    Operátor O2 má opět problémy. Jako omluvu za pondělní zhoršenou dostupnost služeb dal všem zákazníkům poukaz v hodnotě 300 Kč na nákup telefonu nebo příslušenství.

    Ladislav Hagara | Komentářů: 5
    dnes 05:55 | IT novinky

    Společnost OpenAI představila GPT-5 (YouTube).

    Ladislav Hagara | Komentářů: 0
    dnes 05:00 | Nová verze

    Byla vydána (𝕏) červencová aktualizace aneb nová verze 1.103 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.103 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.

    Ladislav Hagara | Komentářů: 0
    včera 17:33 | IT novinky

    Americký prezident Donald Trump vyzval nového generálního ředitele firmy na výrobu čipů Intel, aby odstoupil. Prezident to zdůvodnil vazbami nového šéfa Lip-Bu Tana na čínské firmy.

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

    Bylo vydáno Ubuntu 24.04.3 LTS, tj. třetí opravné vydání Ubuntu 24.04 LTS s kódovým názvem Noble Numbat. Přehled novinek a oprav na Discourse.

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

    Byla vydána verze 1.89.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

    Ladislav Hagara | Komentářů: 0
    včera 12:22 | IT novinky

    Americká technologická společnost Apple uskuteční v USA další investice ve výši sta miliard dolarů (2,1 bilionu korun). Oznámil to ve středu šéf firmy Tim Cook při setkání v Bílém domě s americkým prezidentem Donaldem Trumpem. Trump zároveň oznámil záměr zavést stoprocentní clo na polovodiče z dovozu.

    Ladislav Hagara | Komentářů: 4
    včera 04:55 | Nová verze

    Zálohovací server Proxmox Backup Server byl vydán v nové stabilní verzi 4.0. Založen je na Debianu 13 Trixie.

    Ladislav Hagara | Komentářů: 0
    Kolik tabů máte standardně otevřeno ve web prohlížeči?
     (45%)
     (21%)
     (4%)
     (6%)
     (3%)
     (1%)
     (1%)
     (19%)
    Celkem 306 hlasů
     Komentářů: 23, poslední 4.8. 13:01
    Rozcestník

    Dotaz: C sleep & sleep & recv deadlock

    28.4.2023 10:27 iko | skóre: 7
    C sleep & sleep & recv deadlock
    Přečteno: 860×

    Zdravim vospolok

    Mam program v c++, 3 vlakna, jedno vlakno prijma pakety zo siete, druhe vykonava cinnost, tretie tiez nejaku cinnost. V kazdom vlakne sa obcas pouziva funkcia usleep. Problem nastava, ze na pravdepobone novomkerneli sa tie vlakna locknu a vsetko zostane visiet a nic sa nerobi.

    Vyzera to ako keby sa tie usleepy lockli v kerneli alebo co. System Fedora 36, kernel-6.2.11-100.fc36.x86_64. Napada niekoho nieco?

    Tu je z callstack debugera:

    Thread 1

    #0 __kernel_vsyscall () at arch/x86/entry/vdso/vdso32/system_call.S:72 #1 0xf792043b in __GI___clock_nanosleep_time64 (clock_id=<optimized out>, flags=0, req=0xff94d3b8, rem=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:62
    #2 0xf7925fe9 in __GI___nanosleep64 (rem=0x0, req=0xff94d3b8) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
    #3 __GI___nanosleep (req=0xff94d404, rem=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:42
    #4 0xf7961fe3 in usleep (useconds=1000) at ../sysdeps/posix/usleep.c:31

    Thread 2

    #0 __kernel_vsyscall () at arch/x86/entry/vdso/vdso32/system_call.S:72
    #1 0xf796bcec in __libc_recv (fd=4, buf=0xf51fec3c, len=10, flags=0) at ../sysdeps/unix/sysv/linux/recv.c:30

    Thread 3

    #0 __kernel_vsyscall () at arch/x86/entry/vdso/vdso32/system_call.S:72
    #1 0xf792043b in __GI___clock_nanosleep_time64 (clock_id=<optimized out>, flags=0, req=0xf13302a8, rem=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:62
    #2 0xf7925fe9 in __GI___nanosleep64 (rem=0x0, req=0xf13302a8) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
    #3 __GI___nanosleep (req=0xf13302f4, rem=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:42
    #4 0xf7961fe3 in usleep (useconds=60000000) at ../sysdeps/posix/usleep.c:31

    Odpovědi

    28.4.2023 10:41 iko | skóre: 7
    Rozbalit Rozbalit vše Re: C sleep & sleep & recv deadlock
    To iste to robi aj ked zrusim vlakno 3, cize sa lockne recv a usleep.
    28.4.2023 11:01 Radek Isa | skóre: 14
    Rozbalit Rozbalit vše Re: C sleep & sleep & recv deadlock
    Tak jak jsi to pospal, tak vypadá, že došlo k uváznutí. Zmiňuješ funkci sleep, která nejspíše nemá s problémem nic společného nebo je to velké fuj. Provádět synchronizaci pomocí funkce sleep je vyloženě hazard a nikdy nevíš, kdy ti může dojít k race condition. Správně pro synchronizaci by se měly použit semafory, nebo monitory.
    AraxoN avatar 30.4.2023 07:03 AraxoN | skóre: 47 | blog: slon_v_porcelane | Košice
    Rozbalit Rozbalit vše Re: C sleep & sleep & recv deadlock
    Stane sa niečo, keď pošleš tomu procesu SIGALRM? To by malo prerušiť sleep...
    30.4.2023 21:28 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Hovno

    Jako další postup navrhuji:

    1. Zveřejnit vhodný MWE. Bez MWE, který problém předvádí a izoluje, se dá jedině věštit z křišťálových koulí.
    2. Odstranit sleep() ve všech podobách. Nikdy nemá smysl a jen škodí. Nepatří do userspace. Jen v kernelu může mít (velmi) omezené uplatnění. Pak zkusit celý problém reprodukovat.
    2.5.2023 08:04 tom
    Rozbalit Rozbalit vše Re: Hovno
    Ale prd, pozastaveni se normalne pouziva (spis teda pres clock_nanosleep nez nanosleep) u vsech programu co polluji, protoze ve spouste usecase to vede k vetsi propustnosti nez kdyz je producent prace bude budit.
    2.5.2023 11:35 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: Hovno
    …pozastaveni se normalne pouziva…

    Ale prd. Že někdo píše špatný software, to ještě neznamená, že „se“ takové postupy používají běžně všude.

    …to vede k vetsi propustnosti…

    Nevede to ani omylem k větší propustnosti; tak tenhle svět nefunguje. Vede to (někdy, výjimečně, při pečlivém načasování) k nižší latenci.

    Nejvyšší propustnost přijde v situaci, když bude konzument zcela saturovaný producentem, nikdy se neuspí a bude žrát nějakou (ideálně) neblokující frontu. Tam sleep() opravdu (ale opravdu) nebude hrát roli.

    Především, program v userspace nemá co/proč pollovat. (Pokud nedělá něco ultra-hardwarově-nízkoúrovňového, jenže v takovém případě není v userspace, takže nic.) Polling v různých podobách a granularitách se už děje automaticky jako součást prakticky všech UNIXových synchronizačních primitiv. Žádný (kni)hovní zamykací mechanismus (například z pthread.h) nezačne bezhlavě volat po context-switchi, aniž by se napřed pokusil o spinlock atd. atp.

    Taková↑ (kni)hovní implementace je většinou dobře odladěná a optimalizovaná pro danou platformu, umí použít lock elision, kde to jde (jo, to bývaly časy, když ještě fungovaly TSX), a nějaký program v userspace by se neměl neomaleně pokoušet dělat znova něco podobného.

    Pokud bych opravdu potřeboval pollovat (a to bych nepotřeboval), mám k tomu spousty lepších prostředků než sleep(). timer_create() a timer_settime() například, kdybych se chtěl nechávat vyrušit z téměř libovolného blokujícího spaní. Nebo spoustu „timed“ variant funkcí, jako sigtimedwait(), sem_timedwait(), pthread_cond_timedwait() atd. atp.

    2.5.2023 17:21 tom
    Rozbalit Rozbalit vše Re: Hovno
    Priklad zadani:
    • Mam 16 producentu, ktery generujou zpravy o velikosti ~100B
    • Vsechny tydle zpravy je potreba nacpat do 4 sifrovacich akceleratoru.
    • Z pozadavku na odezvu systemu vim, ze zprava nesmi byt zdrzena dele nez 200us nez se preda do akceleratoru. Vyprazdnovat frontu muzu rychlosti 12Gb/s.
    Z tohodle si spocitam, ze muzu mit frontu max. 3200 zprav abych dodrzel limit na odezvu. Podle rychlosti generatoru a jejich agregaci a rychlosti si spocitam, ze tech 3200 zprav vygenerujou napr. za 500us. Potom vim, ze pokud je prazdna fronta, muzu temer 200us spat nez zacnu konzumovat zpravy. Kdyz mi vyjde, ze ty zpravy vygenerujou za 150us, tak rovnou vim, ze to nikdy fungovat nemuze a musim zmenit agregaci (a mozna pridat akceleratory).

    Tento pristup: - Minimalizuje pocet prepinani kontextu pri zatizenem systemu, protoze pri jednom behu se zpracuje maximalni mnozstvi dat. - Odstrani nutnost udrzovat sdileny counter informujici o mnozstvi zprav ve fronte. Counter by vyzadoval synchronizaci i mezi producenty, coz muze byt drahe. U takto kratkych zprav to klidne muze sebrat az 10% strojoveho casu, pokud se citac bude aktualizovat po kazde zprave. - Odstrani problem s probouzenim: Ktery producent ma vzbudit konzumenta? A kdy to ma udelat?

    Na dukaz, ze se toto opravdu pouziva, se doporucuju podivat jak v Linuxu funguje NAPI, ktere pouziva vetsina sitovych ovladacu. To, ze NAPI je v kernelu, je uplne putna, protoze to je klasickej producent/consumer problem a uplne stejne se to da naprogramovat i v user space.

    Založit nové vláknoNahoru

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

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