Jaderné noviny – 23. 2. 2012: Co dělat se sleep(0) (diskuse)

[aaaaaaaaaaaaaaaa]

Preco je sched_yield() spatny napad? Ja som ho napriklad pouzil vo viacvlaknovom programe, ked mi pri specifickej datovej strukture (kt. si konzistenciu zarucovala sama) nastala kolizia a nechcel som, nech sa 1 vlakno so "spinlockom" toci dlhu dobu (toto tocenie v cykle program viditelne spomalovalo). "Klasicke" zamykanie a semafory som nemohol pouzit, lebo ich obsluha bola pomerne draha v pripade, ze kolizia nenastala. sched_yield() nielenze zabranilo vytazovaniu CPU tocenim sa v cykle, ale zaroven to zrychlilo aj vykonavanie programu - pravdepodobne preto, lebo sa dostalo druhe vlakno na radu skor.

Pravdupovediac, veci ako sleep(0) by ma nikdy nenapadli, lebo sa mi zdaju byt nelogicke, uz pri precitani nazvu. Na prvy pohlad ide o nahodne side efekty a teda sa na ne neda spolahnut. Urcite by som sa s tym netrapil, ako opisani vyvojari.

[bflmpsvz]

sched_yield() je špatné proto, že když ten proces má realtimovou prioritu, tak ho neuspí, prostě bude dál provádět realtimový proces s nejvyšší prioritou. Čili když budeš pomocí sched_yield() synchronizovat realtimový a nerealtimový proces nebo dva realtimové procesy s různou prioritou, tak to může vytuhnout. Může se stát, že proces s vyšší prioritou bude pořád dokola volat sched_yield(), čekat na uvolnění zámeku, zatímco proces s nižší prioritou (který by eventuálně mohl ten zámek uvolnit) nebude nikdy spuštěn.

Pokud čekáš na událost opakovaným testováním, je lepší tam dát sleep třeba na tisícinu sekundy. To bude fungovat i když uživatel nastaví realtimovou prioritu těch procesů.

[Atom321]

Pokud se zámek volá 100000x za sekundu a v 1% dojde ke kolizi, bude takový program jen čekat.

Na synchronizaci přístupu jsou funkce pthread_mutex_lock()/pthread_mutex_unlock().

[Sten]

pthread_mutex funkce jsou systémově velice náročné, u míst, kde se nepředpokládají časté kolize, ale je potřeba často zamykat (typicky u konfigurace aktualizované přes RCU), se používají user-space spinlocky + pthread_yield, když už to selže. Nicméně mnoho vývojářů jaksi zapomíná, že na to musí mít všechna vlákna stejnou prioritu. No alespoň že na Linuxu jsou futexy.

[Atom321]

Spinlock má smysl, jen pokud kolidující thready běží na různých CPU. S pthread_yield() nijak nezaručíte, že scheduler přepne právě na thread držící zámek. Nebo ještě hůře, druhý thread může zámek pustit, chvíli něco dělat, pak znovu zamknout. V tu chvíli vyprší čas a scheduler znovu přepne ...

Na Linuxu tohle všechno řeší novější implementace pthread_mutex_lock() knihovny NPTL, která nejprv zkouší rychlou cestu v userspace (test&set), při kolizi použije čekací frontu přes syscall futex().

[Sten]

U RCU se spinlock exkluzivně zamyká jenom ve chvíli, kdy se dělá update, takže tam by s tím problém nebyl, update je výjimečný a pravděpodobnost, že nastane dvakrát za sebou ve stejném vlákně, je prakticky nulová.

NPTL používá test&set? Hmm, tak to by stálo za to pthread mutexy opět začít používat

[Jindřich Makovička]

Někdy je ale potřeba dát pozor na to, že se NPTL mutexy chovají trochu nevyzpytatelně. Třeba zkoušíte přidávat klienty vašeho serverového procesu, proces v pohodě běží a zabírá 50% cpu, načež přihodíte jednoho dalšího klienta, server se úplně zastaví a cpu load je 100%. To proto, že převážily kolize a veškerý CPU čas se najednou tráví ve futex_wake().

[Sten]

Stejný problém mají spinlocky, snadno se může stát, že vláken je příliš mnoho a procesorů málo, a pak to tráví hodně času přepínáním kontextů (nebo čekáním na změnu hodnoty, pokud je to pure user-space spinlock), takže s tím problém nemám, to si zvládne ohlídat thread pool.

[Martin Mareš]

U RCU se spinlock exkluzivně zamyká jenom ve chvíli, kdy se dělá update, takže tam by s tím problém nebyl, update je výjimečný a pravděpodobnost, že nastane dvakrát za sebou ve stejném vlákně, je prakticky nulová.

Moc nerozumím tomu, k čemu je na RCU potřeba zamykat čtení. Na to by přeci měla stačit atomická proměnná.

[Sten]

Pokud je paměť uvolňována asynchronně, tedy uvolňuje ten, kdo čte, tak stačí atomická proměnná, pokud ji ale chcete uvolňovat synchronně (tj. vědět, kdy už všichni používají novou verzi), tak je potřeba zamykat.

[Sten]

Btwe. spinlocky jsou implementované pomocí atomických proměnných

[Martin Mareš]

Otázka je, zda synchronní uvolňování má jakoukoliv zajímavou výhodu, speciálně takovou, která by vyvážila cenu zamykání.

[Sten]

Zamykání pro čtení je u spinlocku velice levné, protože to je jen inkrementace atomické proměnné, což u RCU musíte dělat stejně. Výhodou může být třeba to, že víte, že nějaký logovací nebo dumpovací soubor už nemůže být otevřený, a tak ho můžete odeslat přes síť nebo zagzipovat, nebo že můžete smazat nějakou tabulku v databázi, kterou už nebudete potřebovat. U samotné aplikace by to vyřešil destruktor té sdílené struktury, ale když to třeba chcete provázat se shellem nebo nějakou webovkou, tak se taková možnost synchronizace hodí.

[Martin Mareš]

Zamykání pro čtení je u spinlocku velice levné, protože to je jen inkrementace atomické proměnné,

Jen? Inkrementace atomické proměnné je docela drahá operace, protože zpusobuje, že si procesory příslušný cacheový řádek pinkají mezi sebou po poměrně pomalé sběrnici.

což u RCU musíte dělat stejně.

Opravdu? Nestačí mi atomickou proměnnou číst?

[Sten]

Jen? Inkrementace atomické proměnné je docela drahá operace, protože zpusobuje, že si procesory příslušný cacheový řádek pinkají mezi sebou po poměrně pomalé sběrnici.

Ve srovnání s voláním jádra, co dělají semafory a dělaly mutexy, je to velmi levné.

Opravdu? Nestačí mi atomickou proměnnou číst?

A kdo bude uklízet?

[Martin Mareš]

Ve srovnání s voláním jádra, co dělají semafory a dělaly mutexy, je to velmi levné.

To ano, ale dá se obejít i bez toho.

(Mimochodem, pod Linuxem by ani semafory neměly v případě, že nečekají, volat jádro.)

A kdo bude uklízet?

Dá se to udělat například tak, že každé vlákno jednou za čas projde nějakým synchronizačním bodem, ve kterém je jisté, že zrovna do žádné datové struktury nekouká, a přitom zvýší per-thread čítač. Uklízecí vlákno pak po čase podle čítačů zjistí, že do staré verze struktury už dávno nikdo nekouká, a uvolní ji.

[Sten]

Takže garbage collector? To je ale výkonově o dost pomalejší, ne? Ten čítač čtenářů se, když je dobře udělaný, zvyšuje jenom jednou na každý update.

[Ivan]

kdysi probihala dodobna debata na openldap devel. Tam si nekdo stezoval na "usleep(0)" a chtel to nahradit za pthread_yield. Kdyz shrnu tu debatu tak odpoved byla "Protoze Solaris".

[Michal Kubeček]

S těmi složenými závorkami kolem jednořádkových větví bych to neviděl tak jednoznačně. Některé projekty je v coding style naopak nařizují - a docela chápu proč. Komu se ještě nikdy nestalo, že z nepozornosti přidal druhý příkaz a zapomněl na složené závorky, ať hodí kamenem (netýká se neprogramujících).

[Radovan Garabík]

Komu se ještě nikdy nestalo, že z nepozornosti přidal druhý příkaz a zapomněl na složené závorky, ať hodí kamenem.

Možno kedysi veľmi dávno, ale odkedy používam počítačový jazyk so syntaxou pre normálnych ľudí, tak sa mi to nestalo

[Michal Kubeček]

Přejít kvůli tomu na jazyk se syntakticky významným formátováním mi připadá jako řešit mírně slanější polévku tím, že do ní nakapu tabasco…

[Lol Phirae]

A o tom, že syntakticky "významné" je odsazování, je pak raději taktně pomlčet.

[msk]

No, to si si teda fakt pomohol ...

[Luboš Doležel (Doli)]

Mně. Závorky, když tam jsou, dávám na samostatný řádek a opravdu jsem se nepřehlédl. Mám vizuálně naučené tam v případě více příkazů čekat jakési odsazení...

Samozřejmě, když se musím hrabat v cizím kódu, kde je if(...) {, tak to je jiné, ale v tom se radši ani nehrabu.

[Michal Kubeček]

Myslel jsem spíš chyby typu

   if (cond)
     do_something();
+    do_something_else();
   go_on();

případně

   if (cond)
+    do_something_first();
     do_something();
   go_on();

Právě tomu používání složených závorek i u jednořádkových větví docela účinně předchází.

[Ladicek]

Závorky by měly být ze zákona, ehm, totiž ze syntaxe, povinné. Jako příjemný bonus to řeší gramatickou nejednoznačnost známou též jako dangling else

[Luboš Doležel (Doli)]

Psát kód jako

if (...)
{
    neco();
}

ten kód znatelně protáhne... Stačí jen pár takových ifů pod sebou.

[Atom321]

A co je tak zásadně špatného na delším kódu?

[Martin Mareš]

Už delší dobu pozoruji, že má rychlost porozumění kódu rapidně klesá s klesající hustotou. Co se nevejde najednou na obrazovku, o tom se přemýšlí daleko hůř. Kompaktní Céčkové zdrojáky (tím nemyslím psané nesmyslně nahuštěně, ale prostě bez zbytečných děr) se čtou příjemně. Pokud přibude spousta celořádkových triviálních komentářů, je to znatelně horší. Vrcholem jsou programy v Javě rozdělené na desítky naprosto triviálních tříd plných triviálních metod, navíc každá třída v jiném souboru, ty se nedají číst vůbec.

[Atom321]

Možná máte jen malý monitor

V zásadě s vámi souhlasím, jen některé "díry" nepovažuji za zbytečné. Pro snadnější čitelnost mi dost pomáhá zarovnání párových závorek pod sebou a jistá uniformita zdrojáku. Prostě pod každým if automaticky očekávám blok ve složených závorkách. Je to ale nejspíš jen síla zvyku.

[Heron]

Jenže právě proto, že jsou to triviální metody, je celá jejich funkce popsána jejich názvem, takže netřeba číst jejich kód. Takový zdroják se mi naopak dobře čte - metoda o 5 řádcích z toho 3 řádky jsou volání jiných metod a vše plyne už z jejich názvu.

Na jednu obrazovku? Metoda delší než pár řádků (5) si zaslouží minimálně zamyšlení nad možností refaktoringu. Někde to nejde, většinou jo.

[Gilhad]

S tim jsem se uz setkal a bylo to na zabiti - autor se zhlednul v 3 radkovych funkcich, kazdy funkcni kousicek kodu byl zanoreny minimalne v urovni 5 a nedalo se v tom absolutne vyznat. Navic, aby to dokazal takto udrzet, tak skoro vsechno melo nejake vedlejsi efekty. od vypadal uhledne, chyba v nem najit nesla, jenom nefungoval a nevyznal se v nem po par tydnech ani sam autor.

Takze jsem to pak prepsal do neceho, s cim uz se dalo pracovat, vetsina funkci se vesla na jednu obrazovku a delala nejaky rozumny kus prace. Kdyz to nekde vyhodilo chybu, byl zdroj chyby nejspis v okolnich 10 radcich, nikoli v jinem souboru. Zajimave je, ze se vtom dokazi orientovat i jini nez autor a ze je to i po nekolika letech citelne.

[Heron]

tak skoro vsechno melo nejake vedlejsi efekty

Jestli má 3 řádková metoda vedlejší efekt, tak to už musel být skoro kouzelník

Kdyz to nekde vyhodilo chybu, byl zdroj chyby nejspis v okolnich 10 radcich, nikoli v jinem souboru.

Jsem si vždy myslel, že výjimky vznikají v metodách a ne souborech. Zase jsem se něco naučil.

[Gilhad]

Ja aspon povazuju u metody co patri do nejake tridy a ma vratit nejake datum za vedlejsi efekt, kdyz do globalni promenne priradi databazi, kterou otevre s hard-coded jmenem databaze, uzivatele a heslem. Nacez zcela jina metoda jine tridy se spolehne na to, ze prez tu globalni promennou se dostane k otevrene databazi

vyjimky vznikaji v metodach, chyby vznikaji v kodu, pad programu vypise chybu a udeje o tom, co se nepovedlo. Pokud se treba nepovede v jedne metode zvysit hodnotu promenne o jedna, protoze ona hodnota je nedefinovana a promenna dostane prirazenou hodnotu ve zcela jine metode, co je umistena ve zcela jinem souboru, ale dostane ji pouze v 9 pripadech z 10 protoze jedna vetev if-u je nedoresena, tak je zdroj chybu v tom souboru s nedomyslenou inicializaci, ale chyba se projevi v souboru, kde se ta hodnota zvysuje. Protoze vetsinou neni kod programu a vsech knihoven jen v jednom jedinem souboru.

v nove verzi, pokud to nekde spadlo, tak misto vzniku chybu (neosetreni cehosi) bylo vetsinou jen par radku od mista projevu chyby. Cimz se hledani dost usnadni, pokud clovek nemusi prolezt deset souboru, nez se dostane ke zdroji, ale zdroj je jen o par radku vys, nez to, kde se chyba projevi.

[Heron]

Ten původní kód psalo prase, bez ohledu na to, že dodržovalo nějaké doporučení. Délka metod nemá nic společného s tím, kdy metoda kromě návratu hodnoty také cosi nastaví (nebo naopak nenastaví). Metoda má dělat jen jednu věc a ta věc by měla odpovídat názvu.

promenna dostane prirazenou hodnotu ve zcela jine metode, co je umistena ve zcela jinem souboru

Já v Javě pojem "proměnná v jiném souboru" opravdu neznám. Proměnná je v nějakém objektu (tedy atribut; field), nebo může být v dané třídě statická. Nevím, který z těchto dvou případů to byl, zřejmě se jednalo o nějakou statickou nefinální proměnnou s přístupem public... Jak jsem psal, ten kód psalo prase.

pokud to nekde spadlo, tak misto vzniku chybu (neosetreni cehosi) bylo vetsinou jen par radku od mista projevu chyby

Podle stacktrace se to dá někdy snadno vypátrat (někdy samozřejmě ne), nez ohledu na počet tříd.

[petr_p]

Délka funkce vliv má. Čím je funkce kratší, tím roste potřeba předávat data mimo funkci (protože lexikální platnost proměnných). Data(lze, předávat, přes, parametry), schovat.do.struktury.v.objektu nebo odložit do globální proměnné, tedy způsobit vedlejší efekt. Jakýkoliv zápis přesahující rozumné meze je zrůdný.

[Gilhad]

Samozrejme to byl pripad treti, slo o promennou nalezejici modulu, nikoli nejake tride ci objektu.

Nevim, kde jsi prisel na to, ze by to melo byt v jave. (Zvlast kdyz vlakno zacinalo Cckem). Objekty mely jazyky pred javou a maji jazyky i po jave a na spoustu veci java neni az tak vhodna.

Psat slusne se da v cemkoli, prasit taky.

Podle stacktracu vypatram, kde se inkrementovala promenna bez hodnoty, ale nikoli kde programator udelal chybu v uvaze a vynechal jednu moznou kombinaci pri ktere pak nedoslo k nastaveni dotycne hodnoty nekde zcela jinde, nez se ji pak pokousel inkrementovat.

---

Problem je ze spousta prasat se schovava za poucky, jak ma spravne kod vypadat, aniz by resili proc tomu tak ma byt. Argument "musim pouzivat globalni promenne, jinak by mi vychazely volani moc dlouha a funkce s prilis radky" asi mluvi za vse.

Nektere funkce na me pusobily dojmem, ze puvodne slo o jednu funkci, ktera byla moc dlouha tak proste rozdelil radky do skupin po peti a prohlasil to za funkce, dalsi vrstva volala tyto "funkce" po rade po peti a atd, atd. dokud nedosahl jedne funkce, ktera se vetvila na celou pyramidu. A ve skutecnosti slo o dlouhy flat-code o par urovni niz, jen umele rozdeleny do skatulek.

[Heron]

Nevim, kde jsi prisel na to, ze by to melo byt v jave.

Aha, za to se omlouvám, to poznámku o Javě a tomto způsobu psaní psal někdo jiný, ty jsi potom volně pokračoval o C.

Jinak v podstatě souhlas, pokud někdo používá poučky ad absurdum, k ničemu dobrému to nevede.

[Gilhad]

Ja ve skutecnosti volne navazal Pythonem :) Ale ono je to v podstate obecny, na jazyku nezavisly, problem.

[Jindřich Makovička]

Dobře to popisuje ESR v The Art of Unix Programming. Když se problém rozdrobí moc, jednotlivé metody/třídy/moduly jsou sice triviálně jasné, ale složitost interakcí mezi nimi přeroste únosnou mez.

[Martin Mareš]

Jenže právě proto, že jsou to triviální metody, je celá jejich funkce popsána jejich názvem, takže netřeba číst jejich kód. Takový zdroják se mi naopak dobře čte - metoda o 5 řádcích z toho 3 řádky jsou volání jiných metod a vše plyne už z jejich názvu.

Pak její zápis měří o 4 řádky víc, než je zdrávo. Daleko lepší je napsat:

method catch() { .bark; .bite; .tail.wag; }

Věnovat takovému štěku víc než jeden řádek je nestoudné plýtvání elektrony, prostorem ve Vesmíru i čtenářovou pozorností.

Někde to nejde, většinou jo.

Jenže i když to jde, často je to na škodu celkové čitelnosti kódu.

Nedává smysl optimalizovat na čitelnost jedné metody (zvlášť když nic zajímavého nedělá). Daleko důležitější je, jak je snadné pochopit celou třídu.

[Michal Kubeček]

Vrcholem jsou programy v Javě rozdělené na desítky naprosto triviálních tříd plných triviálních metod, navíc každá třída v jiném souboru, ty se nedají číst vůbec.

No tak zrovna v tomhle ohledu na tom některé části linuxového jádra nejsou o moc lépe. Běžně se mi stává, že abych zjistil, co vlastně dělá určitá funkce, musím postupně projít čtyři funkce, na střídačku z adresáře příslušného subsystému a include. Při troše smůly se do toho zamíchá ještě nějaké těžko dešifrovatelné makro a když je smůly víc, tak jako bonus arch a include/asm.

[Michal Vyskočil]

S tím budou souhlasit tak leda Pythonisti

Takže +1

[Ladicek]

Proboha! Asi jsem Pythonista!

[pavlix]

Já asi taky! :D

[msk]

Závorky by měly být ze zákona

Suhlasim.

[Luboš Doležel (Doli)]

Já tomu rozumím. Ale první případ se mi nestane nikdy, protože auto indent to hned odhalí, a tak či tak mě oba ihned praští do očí. Fakt se mi to nestalo. Než něco připisuju, tak úplně automaticky připíšu závorky.

[Jindřich Makovička]

Dělám v kódu nepochybně spoustu bot, ale zrovna tenhle druh si nevybavuju už hodně dlouho. Při zapnutém automatickém odsazování je taková chyba okamžitě vidět.

[Heron]

Souhlasím a rozšířil bych to i na SQL. Jeden příkaz se provede v autocommit režimu, takže mnozí jej zapomínají ohraničit BEGIN a COMMIT. Jenže potom tam někdo přidá další query (a nebejbože nějaký příkaz na změnu dat) a hnedle jsou z toho dvě nezávislé transakce místo zamýšlené jedné.

[Šangala]

Dík za vysvětlení, já jsem furt nechápal proč má to štěně chcípnout.
A popravdě, už jsem tedy zabil hodně štěnat…

[Voty]

Uff, doufám, že pokud píšu stylem

if(...) {
  on_line_statement();
}      

tak chcípně vždy je 1/2 štěňátka.

[pjoter]

Hm, kdyz uz, tak bud konzistetni

if (...) {

:)

[pjoter]

A dalsi vec proc tam ty zavorky radeji davam je ta, ze pokud totiz tu cast kodu bez tech zavorek upravim a pridam k tomu jednomu radku nejaky dalsi kod (+ ty dve zavorky), tak to zbytecne pridava bordel do patche/commitu (dva radky zbytecne navic). Jinymi slovy to usnadnuje review.

[Martin Mareš]

To nedává smysl, protože celková velikost obou patchů (ten, který kód založil, a ten, který ho modifikuje), zůstává zachovaná. Leda byste víckrát příkazy přidával a odebíral :)

Ale tak jako tak, přítomnost prázdných řádků nebo řádků se závorkami review patche prakticky nijak neovlivňuje.

[m;)]

s dtrace pre linux to nie je take horuce ani slavne .. http://dtrace.org/blogs/ahl/2012/02/23/dtrace-oel-update/