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

5. 3. 2012 | Luboš Doležel | Jaderné noviny | 4151×

Aktuální verze jádra: 3.3-rc4. Citát týdne: David Miller. Náprava ABI sys_poll(). dma-buf a proprietární moduly. Oracle nabízí DTrace pro Linux. Co dělat se sleep(0).

Obsah

• Aktuální verze jádra: 3.3-rc4
• Citát týdne: David Miller
• Náprava ABI sys_poll()
• dma-buf a proprietární moduly
• Oracle nabízí DTrace pro Linux
• Co dělat se sleep(0)

Aktuální verze jádra: 3.3-rc4

Aktuální vývojová verze jádra je 3.3-rc4 vydaná 18. února, což je o pár dnů později, než se čekalo. Tentokrát je důvodem pro zpoždění to, že nám trvalo několik dnů, než jsme vystopovali narušování stavu plovoucích čísel, ke kterému docházelo na 32bitovém x86 – ale jen pokud jste měli moderní CPU (proč pak používáte 32bitová jádra?) s podporou instrukcí AES-NI. A pak jste museli zapnout podporu těchto instrukcí *a* použít bezdrátový ovladač, který jich využívá. Nejpravděpodobnějším důvodem je používání infrastruktury mac80211 s WPA se šifrováním AES (tedy typicky WPA2). Dále se dostalo i na řadu dalších oprav; krátký seznam změn najdete v oznámení.

Stabilní aktualizace: verze 3.0.22 a 3.2.7 byly vydány 20. února; obsahují obvyklý výčet důležitých oprav.

Citát týdne: David Miller

Když napíšete

if (ret) {
        one_line_statement();
}

tak někde umře štěňátko. A lidi od DRM právě odrovnali celý útulek.

-- David Miller

Náprava ABI sys_poll()

Systémové volání poll() má tři parametry, jedním z nich je hodnota časového limitu (timeout), která určuje horní mez (v milisekundách) toho, jak dlouho bude proces čekat. Manuálová stránka říká, že typem této hodnoty je int. Z důvodů, které už dávno zapadly v historii, interní jaderná implementace poll() vždy očekávala hodnotu časového limitu v podobě long. A to bylo zdrojem občasných bugů.

Většinou to funguje, jak má. Typy int a long jsou na většině architektur shodné a pokud už se liší, tak se glibc postará o příslušnou změnu se zachováním znaménka. Pokazí se to ale právě tehdy, když 32bitový proces běží na systému x86-64. V tomto případě 32bitová funkce sys_poll() předá hodnotu nativnímu jadernému protějšku jen tak, aniž by docházelo ke znaménkové úpravě. Takže pokud je hodnota záporná (značící, že poll() může klidně čekat donekonečna), jádro místo ní uvidí velkou kladnou hodnotu.

Problém se dá opravit několika způsoby. Linus se rozhodl pro změnu parametru časového limitu na int v jádře. Díky tomu, že teď je timeout 32bitovou hodnotou na všech systémech, je hned o jednu příčinu zmatků méně. Tento přístup má ale jedno drobné riziko: nelze vyloučit, že existuje nějaká aplikace, která skutečně používala 64bitové timeouty. Aby taková aplikace mohla fungovat, znamenalo by to obcházení glibc (protože její operace se znaménky používání 64bitových hodnot znemožňuje), tudíž je nepravděpodobné, že se s tím někdo někdy obtěžoval, ale kdo ví. Pokud by tato změna nějakou skutečnou aplikaci porouchala, musel by se patch zase odstranit a muselo by se najít nějaké komplikovanější řešení.

Linusův patch byl začleněn do verze 3.3-rc5, takže máte několik týdnů na vyjádření svých obav.

dma-buf a proprietární moduly

Mechanismus pro sdílení bufferů DMA byl zařazen do jádra verze 3.3; jde o možnost, jak pod taktovkou uživatelského prostoru umožnit sdílení bufferů DMA mezi nezávislými ovladači zařízení. Patche dma-buf v podobě, v jaké byly začleněny do verze 3.3, obsahují řadu funkcí, které ovladače používají pro přístup k takovým bufferům; tyto funkce jsou exportovány jako „pouze pro GPL“. Kvůli tomu se ozval Robert Morell z NVIDIA, kterému se pochopitelně nelíbilo, že by toto rozhraní nebylo přístupné proprietárnímu ovladači z dílny jeho firmy.

Moc čtenářů asi nepřekvapí, že reakce na Robertovu stížnost nebyly zrovna plné pochopení. Po chvíli diskuze utichla bez jakéhokoliv řešení. Nedávno ale Rob Clark zpravil svět o debatě, která proběhla na Embedded Linux Conference:

V reakci na proběhlou debatu musím souhlasit, že infrastruktura dma-buf je zamýšlena jako rozhraní mezi subsystémy ovladačů. A protože (prozatím) veškerá podpora pro ARM SoC GL bohužel znamená používání uzavřeného kódu v uživatelském prostoru a protože považuji uživatelský prostor a jádro v oblasti grafických ovladačů za úzce provázané, nemyslím si, že se zde můžeme odvolávat na nějaký zavedený morální standard. Tudíž nemohu namítat proti tomu, aby se místo EXPORT_SYMBOL_GPL() objevilo EXPORT_SYMBOL().

Od té doby se o tom už nemluvilo; stejně tak se ani v jádře nic ohledně těchto funkcí nezměnilo. Změna tónu ve výše citovaných větách může znamenat, že se snad postoje lidí obměkčují a že API pro sdílení bufferů bude nakonec dostupné i pro proprietární moduly.

Oracle nabízí DTrace pro Linux

Oracle oznámil dostupnost betaverze trasovacího frameworku DTrace, který byl přeportován na jejich „Unbreakable Enterprise Kernel“. Ohledně toho, jak port funguje nebo jak se používá, se tohoto teď moc neví; linuxové fórum DTrace zatím zeje dost prázdnotou. Ukázka použití je ale k mání v blogovém zápisku od Wima Coekaertse.

Co dělat se sleep(0)

Obecně platným pravidlem vývojářů jádra je vyhýbat se rozbíjení kódu v uživatelském prostoru, i když je takový kód často vnímán jako principiálně špatný. Ale jsou tu i výjimky; nedávná debata týkající se chování časovače může být ukázkou, jak k takovým výjimkám může dojít.

Standardní céčková funkce sleep() má tu definici, že uspí volající proces na alespoň tolik sekund, kolik bylo určeno. Člověk by si mohl myslet, že volání sleep() s argumentem nula asi moc nedává smysl; proč uspávat procesor na 0 sekund? Jenže se ukázalo, že někteří vývojáři dělají taková volání, aby se CPU na chvilku vzdali. Smyslem je chovat se slušně a před pokračováním v práci nechat krátce běžet i jiné procesy. Aplikace, které dělají polling nebo jsou z jiného důvodu náchylné k přílišnému vytěžování CPU, jsou často „napravovány“ voláním nulových sleepů.

Bylo nebylo za horami v zemi Linuxu, sleep(0) vždy uspával volající proces na alespoň jeden ti(c)k hodin. S příchodem časovačů o vysokém rozlišení do jádra se toto chování změnilo; pokud proces požádal o uspání na vypršeném časovači (což je situace sleepu na nula sekund), volání se jednoduše vrátilo zpět do volajícího procesu. Pak bylo přidáno polevování časovačů [timer slack], které může protáhnout čekání s cílem probouzet najednou hned několik procesorů. Toto chování způsobuje to, že časovače běží o trochu déle, než se žádalo, ale výsledkem je méně probouzení procesorů a tudíž úspora energie. V případě sleepu na nula sekund přidání polevování časovačů mění vypršený časovač na nevypršený časovač, takže volající proces je opět uspáván.

Výchozí polevování trvá 50 µs, takže je nepravděpodobné, že by to ve většině aplikací způsobovalo viditelné změny. Ale zdá se, že na některých systémech je tato hodnota nastavena trochu moc vysoko – v řádu sekund – aby se dosáhlo největších úspor energie. To pak odpovídajícím způsobem může prodloužit sleep a tedy aplikace trochu porouchat.

Matthew Garrett, který zastává názor, že není dobré aplikace rozbíjet, zaslal patch, který sleepy na nula sekund speciálně ošetřuje. Myšlenka je prostá: pokud je požadovaný čas nulový, polevování se mu vyhne a proces nebude uspáván po neurčitou dobu. Problémem tohoto přístupu k věci je to, že proces stále nedocílí kýženého výsledku: namísto vzdání se procesoru jen dojde ke zbytečnému systémovému volání a proces bude zase pokračovat v tom, co dělal doposud. Bez polevování časovačů se požadavek na uspání nad vypršeným časovačem vrátí hned zpátky do uživatelského prostoru, aniž by jakkoliv prošel plánovačem.

Alternativou by bylo přeměnit volání sleep(0) na volání sched_yield(). Jenže tento nápad se netěší popularitě mezi vývojáři plánovače, kteří si myslí, že volání sched_yield() jsou téměř vždy špatný nápad. Říkají, že je lepší opravit aplikace tak, aby přestaly dělat polling nebo obecně to, o čem si vývojáři myslí, že je dobrým důvodem k explicitnímu vzdávání se procesoru.

Podle Matthewa se to týká nemalého množství aplikací:

Testování na Fedoře odhalilo přibližně 125 balíčků z 11000 nebo tak nějak, takže přibližně 1 % uživatelského prostoru v některých situacích používá sleep(0). Všechno v distribuci asi opravit můžeme, ale i tak to znamená, že je na světě znatelné množství kódu, které je porouchaný.

Obvyklým přístupem při vývoji jádra by bylo vyhnout se rozbíjení těchto aplikací. I když aplikace závisí na nedefinovaném nebo nedokumentovaném chování – což je rozhodně tato situace – je stále lepší, když aktualizace jádra nepromění funkční kód v rozbitý. Někteří účastníci se vyjádřili v tom smyslu, že by se tak mělo postupovat i tentokrát.

Situace kolem sleep(0) se ale od jiných trochu liší. Vývojáři aplikací se v tomto případě nemohou odvolávat na dlouhodobě funkční chování, protože během poslední desítky let se reakce jádra na sleep(0) několikrát změnila. A podle Thomase Gleixnera je těžké poznat, kdy by se k takovému volání mělo přistupovat jinak nebo co by se mělo dělat:

Krucinál, nemůžeme přece dát dohromady rozumnou definici, jak takovou věc odlišně ošetřit, protože prostě není ani možné udělat jasnou hranici, co je zvláštní případ a co ne. A neexistuje žádná rozumná definice, co dělat – hned se vrátit nebo projít přes schedule() nebo něco jiného.

Thomas má obavy, že by se pak lidé mohli dovolávat zvláštního ošetřování u podobných volání – například u nanosekundové obdoby nanosleep() – a výsledkem by pak bylo hromadění nepořádku v hlavním kódu časovače. Takže než abychom se snažili tyto případy definovat a donekonečna museli výsledek tohoto snažení udržovat, si myslí, že bychom měli v případech, kdy je polevování časovače nastaveno na velkou hodnotu, nechat postižený kód svému osudu. A v tomto bodě diskuze odezněla, což znamená, že se ohledně omezení dopadu polevování časovače asi nebude nic dělat.

       

Komentáře

[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/