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 01:22 | Nová verze

    Byla vydána nová verze 1.12.0 dynamického programovacího jazyka Julia (Wikipedie) určeného zejména pro vědecké výpočty. Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Aktualizována byla také dokumentace.

    Ladislav Hagara | Komentářů: 0
    včera 15:11 | Bezpečnostní upozornění

    V Redisu byla nalezena a v upstreamu již opravena kritická zranitelnost CVE-2025-49844 s CVSS 10.0 (RCE, vzdálené spouštění kódu).

    Ladislav Hagara | Komentářů: 4
    včera 14:00 | IT novinky

    Ministr a vicepremiér pro digitalizaci Marian Jurečka dnes oznámil, že přijme rezignaci ředitele Digitální a informační agentury Martina Mesršmída, a to k 23. říjnu 2025. Mesršmíd nabídl svou funkci během minulého víkendu, kdy se DIA potýkala s problémy eDokladů, které některým občanům znepříjemnily využití možnosti prokázat se digitální občankou u volebních komisí při volbách do Poslanecké sněmovny.

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

    Společnost Meta představila OpenZL. Jedná se o open source framework pro kompresi dat s ohledem na jejich formát. Zdrojové kódy jsou k dispozici na GitHubu.

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

    Google postupně zpřístupňuje českým uživatelům Režim AI (AI Mode), tj. nový režim vyhledávání založený na umělé inteligenci. Režim AI nabízí pokročilé uvažování, multimodalitu a možnost prozkoumat jakékoliv téma do hloubky pomocí dodatečných dotazů a užitečných odkazů na weby.

    Ladislav Hagara | Komentářů: 0
    7.10. 18:11 | Nová verze

    Programovací jazyk Python byl vydán v nové major verzi 3.14.0. Podrobný přehled novinek v aktualizované dokumentaci.

    Ladislav Hagara | Komentářů: 2
    7.10. 16:33 | IT novinky

    Bylo oznámeno, že Qualcomm kupuje Arduino. Současně byla představena nová deska Arduino UNO Q se dvěma čipy: MPU Qualcomm Dragonwing QRB2210, na kterém může běžet Linux, a MCU STM32U585 a vývojové prostředí Arduino App Lab.

    Ladislav Hagara | Komentářů: 4
    7.10. 15:55 | Nová verze

    Multiplatformní open source voxelový herní engine Luanti byl vydán ve verzi 5.14.0. Podrobný přehled novinek v changelogu. Původně se jedná o Minecraftem inspirovaný Minetest v říjnu loňského roku přejmenovaný na Luanti.

    Ladislav Hagara | Komentářů: 0
    7.10. 13:22 | Nová verze

    Byla vydána nová stabilní verze 6.10 (YouTube) multiplatformního frameworku a GUI toolkitu Qt. Podrobný přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    6.10. 23:55 | Komunita

    Ubuntu 26.04 LTS bude (𝕏) Resolute Raccoon (rezolutní mýval).

    Ladislav Hagara | Komentářů: 5
    Jaké řešení používáte k vývoji / práci?
     (38%)
     (46%)
     (15%)
     (17%)
     (21%)
     (15%)
     (17%)
     (15%)
     (15%)
    Celkem 198 hlasů
     Komentářů: 13, poslední včera 07:41
    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: 867×

    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.