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

    Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.

    Ladislav Hagara | Komentářů: 1
    2.5. 22:22 | Komunita

    Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).

    Ladislav Hagara | Komentářů: 0
    2.5. 19:11 | IT novinky

    Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.

    Ladislav Hagara | Komentářů: 2
    2.5. 11:22 | Zajímavý projekt

    Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.

    Ladislav Hagara | Komentářů: 2
    2.5. 09:11 | Bezpečnostní upozornění

    Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.

    Ladislav Hagara | Komentářů: 2
    1.5. 20:00 | Komunita

    V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.

    Ladislav Hagara | Komentářů: 2
    1.5. 19:22 | IT novinky

    Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).

    Ladislav Hagara | Komentářů: 0
    30.4. 22:33 | Nová verze

    Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.

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

    Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.

    karkar | Komentářů: 0
    30.4. 12:11 | Humor

    Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).

    Ladislav Hagara | Komentářů: 7
    Jaký filesystém primárně používáte?
     (58%)
     (1%)
     (9%)
     (21%)
     (4%)
     (2%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 510 hlasů
     Komentářů: 19, poslední 30.4. 11:32
    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: 820×

    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.