Dotaz: C sleep & sleep & recv deadlock

[iko]

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

[iko]

To iste to robi aj ked zrusim vlakno 3, cize sa lockne recv a usleep.

[Radek Isa]

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]

Stane sa niečo, keď pošleš tomu procesu SIGALRM? To by malo prerušiť sleep...

[Andrej]

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.

[tom]

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.

[Andrej]

…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.

[tom]

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.