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 17:00 | Upozornění

    Národní identitní autorita, tedy NIA ID, MeG a eOP jsou nedostupné. Na nápravě se pracuje [𝕏].

    Ladislav Hagara | Komentářů: 1
    dnes 16:44 | IT novinky

    Americký výrobce čipů Nvidia se stal první firmou na světě, jejíž tržní hodnota dosáhla pěti bilionů USD (104,5 bilionu Kč). Nvidia stojí v čele světového trhu s čipy pro umělou inteligenci (AI) a výrazně těží z prudkého růstu zájmu o tuto technologii. Nvidia již byla první firmou, která překonala hranici čtyř bilionů USD, a to letos v červenci.

    Ladislav Hagara | Komentářů: 3
    dnes 14:11 | Komunita

    Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).

    Ladislav Hagara | Komentářů: 0
    dnes 13:55 | Nová verze

    TrueNAS (Wikipedie), tj. open source storage platforma postavená na Linuxu, byl vydán ve verzi 25.10 Goldeye. Přináší NVMe over Fabric (NVMe-oF) nebo OpenZFS 2.3.4.

    Ladislav Hagara | Komentářů: 0
    dnes 13:33 | Nová verze

    Byla vydána OpenIndiana 2025.10. Unixový operační systém OpenIndiana (Wikipedie) vychází z OpenSolarisu (Wikipedie).

    Ladislav Hagara | Komentářů: 0
    dnes 13:22 | Zajímavý článek

    České základní a střední školy čelí alarmujícímu stavu kybernetické bezpečnosti. Až 89 % identifikovaných zranitelností v IT infrastruktuře vzdělávacích institucí dosahuje kritické úrovně, což znamená, že útočníci mohou vzdáleně převzít kontrolu nad klíčovými systémy. Školy navíc často provozují zastaralé technologie, i roky nechávají zařízení bez potřebných aktualizací softwaru a používají k nim pouze výchozí, všeobecně známá

    … více »
    Ladislav Hagara | Komentářů: 7
    dnes 05:11 | Komunita

    Během tradiční ceremonie k oslavě Dne vzniku samostatného československého státu (28. října) byl vyznamenán medailí Za zásluhy (o stát v oblasti hospodářské) vývojář 3D tiskáren Josef Průša. Letos byly uděleny pouze dvě medaile Za zásluhy o stát v oblasti hospodářské, druhou dostal informatik a manažer Ondřej Felix, který se zabývá digitalizací státní správy.

    🇹🇬 | Komentářů: 33
    dnes 04:44 | Nová verze

    Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 15.0. Postaven je na Firefoxu ESR 140.

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

    Bylo oznámeno (cs) vydání Fedora Linuxu 43. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách Fedora Magazinu: Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Silverblue a Fedora Atomic Desktops.

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

    Elon Musk oznámil (𝕏) spuštění internetové encyklopedie Grokipedia (Wikipedia). Zatím ve verzi 0.1. Verze 1.0 prý bude 10x lepší, ale i ve verzi 0.1 je podle Elona Muska již lepší než Wikipedia.

    Ladislav Hagara | Komentářů: 20
    Jaké řešení používáte k vývoji / práci?
     (36%)
     (48%)
     (20%)
     (19%)
     (23%)
     (17%)
     (21%)
     (17%)
     (17%)
    Celkem 281 hlasů
     Komentářů: 14, poslední 14.10. 09:04
    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: 869×

    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.