Vícevláknové programování v C++

8.5.2008 17:42 | Přečteno: 4207× | Programování | poslední úprava: 9.5.2008 16:28

Jelikož je dneska SMP všude kolem nás, řekl jsem si, že se v C++ naučím vícevláknově programovat (tady jsem se o tom zmínil) a chtěl jsem se zeptat odkud čerpat informace.

V tomhle směru nemám zkušenosti v žádném programovacím jazyce, takže mi ještě zbejvá pochopit i to, jak to celý funguje - různý locky, výjimky, čtení souboru ve víc vláknech a co já vím.

Nevíte o nějakym dobrym zdroji? Jde mi samozřejmě o POSIXová vlákna (pthread). Potřebuju něco, kde je to dobře vysvětlený a kde je hodně příkladů. V Mistrovství v C++ o tom nic není.

Taky jsem přemejšlel na čem si to vyzkoušet. Nejvíc mě samozřejmě baví programovat věci, který potom nějak využiju, ale když to ještě k tomu skloubím s tím, že to musí bejt něco náročnýho na procesor (aby to mělo smysl dělat ve více vláknech), tak mě nic moc nenapadá... Třeba nějaký enkódování, ale nevím jak moc by mě to bavilo...

Btw. GPL vítězí nad Skype

Update: Tak jsem napsal svou první mt aplikaci. Počítá počet inkrementací za sekundu Pak jsem ale zjistil, že když to napíšu st (pomocí alarm), tak je to sice pomalejší, ale když to optimalizuju s -O3, tak to vyjde nastejno a mt už -O3 nijak nezrychlí. Taky jsem poprvé použil volatile, protože to gcc/g++ s -O3 přeháněl

       

Anketa

Komentáře

[Jary]

Operating Systems: Design and Implementation, (co-authored with Albert Woodhull)

http://cs.wikipedia.org/wiki/IPC (nebo en verze ...) http://cs.wikipedia.org/wiki/Proces_%28po%C4%8D%C3%ADta%C4%8D%29

[Michal Fecko]

Povazuje sa za SMP aj P4 s HT?

[JZ]

Ne, v kernelu je toto označováno jako SMT (symetric multi threading). Nicméně podstata je podobná.

[Chocolate Bear]

Nevim, jsou pthreads dostatečně multiplatformní? Třeba jednou budeš používat nějaký neposixový operační systém, co můžeš vědět. Jinak k tomuhle tématu nemám celkem co říct, ale abych jen tak neplácal, tak zmínim aspoň tuhle knihovnu (It is a library that helps you take advantage of multi-core processor performance without having to be a threading expert.). Taky v boostu je nějakej kolovrátek na vlákna.

[Luboš Doležel (Doli)]

Nevim, jsou pthreads dostatečně multiplatformní? Třeba jednou budeš používat nějaký neposixový operační systém, co můžeš vědět.

Takže Windows? Tak se případně naučí pár funkcí navíc, žádná věda to není.

[Chocolate Bear]

Nevim, přijde mi lepší dělat programy rovnou jako multiplatformní, když tomu nic nebrání. Proč Windows? Dyť je to mladej kluk, za jeho života ještě vznikne. A kdo může říct, jak se zejtra vyspí Steve Jobs a na čem bude založenej třeba Mac OS Y

Tož naučí se, co by se nenaučil, ale ty programy se sami nepřepíšou. No není to škoda? :-P

[Chocolate Bear]

...vznikne spousta operačních systémů.

[Luboš Doležel (Doli)]

Nevim, přijde mi lepší dělat programy rovnou jako multiplatformní, když tomu nic nebrání.

POSIX slouží sám o sobě k multiplatformnímu vývoji. Že je Redmond centrálou blbů, za to ostatní nemůžou. Navíc je to pár funkcí - když si vezmu, že jsem se učil WinAPI, MFC, GTKmm i Qt, připadá mi tato diskuze trochu směšná Spoléhat se na každou věc na nějakou extra knihovnu je zbytečné - a kdo to pak má používat.

[pasmen]

Že je Redmond centrálou blbů...

Proč je Redmond centrálou blbů?

[Luboš Doležel (Doli)]

Protože ve všech situacích, kde je to jen možné, se snaží jít proti dohodnutým standardům - buď vytvořením něčeho vlastního nebo znásilněním něčeho existujícího.

[pasmen]

Neřekl bych, že to dělají jen kvůli tomu, aby šli proti proudu. Nedělají to náhodou proto, že buď jsou toho názoru, že jejich řešení bude ve výsledku lepší, nebo proto, že jim to přinese zisk? Ať tak nebo tak, v tomhle se moc neliší od většiny ostatních firem. A už vůbec mi to nepřijde jako jednání blba.

[Luboš Doležel (Doli)]

Nedělají to náhodou proto, že buď jsou toho názoru, že jejich řešení bude ve výsledku lepší, nebo proto, že jim to přinese zisk?

B je správně, upevňuje to monopol. Nepřijde mi, že bychom na Unixech o něco lepšího přicházeli.

Ať tak nebo tak, v tomhle se moc neliší od většiny ostatních firem.

Když se podívám na ostatní moderní OS, tak ty se POSIXem vesměs řídí. Takže liší.

A už vůbec mi to nepřijde jako jednání blba.

Blbcem jsem nemyslel hloupého člověka, ale spíš něco jako "parchanta" apod.

[pasmen]

Pokud se svobodným (to slovo máte rádi ) OS podaří přesvědčit lidi o tom, že je to ten OS který chtějí/potřebují, pak se monopol někoho jako Microsoft konat nebude. To je ten hlavní problém. Obyčejný user nepotřebuje Linux, když mu všechno "funguje" na Windows. To že je to technicky OS na dvě věci jim fakt nevadí. Pak se ale nemůžeme divit, že se někdo drží na špici způsoby na hraně zákona a pod hranicí etiky.

[Luboš Doležel (Doli)]

To je těžké. Jakmile MS vidí, že někde začíná Linux vynikat, začne tam Windows dumpovat za minimální ceny nebo si začne výrobce zavazovat smlouvami.

[pasmen]

Což je něco mezi sviňárnou (vzhledem k pozici MS na trhu) a nutným krokem (pokud si chce tuto pozici zachovat).

[trekker.dk]

B je správně, upevňuje to monopol. Nepřijde mi, že bychom na Unixech o něco lepšího přicházeli.

Dneska se celý den pokouším portovat svůj program, který komunikuje po sériovém portu, aby fungoval i ve Windows. A jak to v Linuxu šlo jednoduše, tak to v moftech jde složitě.

Bych řekl, že na Unixech přicházíme o způsob, jak snadno zabít spoustu času.

[Jary]

Vsadil bych boty i trenýrky, že na to jsou multiplatformní knihovny.

[Michal Kubeček]

Na to zabití spousty času? :-)

[trekker.dk]

Tak na GUI používám Qt, v tom problém není.

Nicméně co se týče toho sériáku, tam je to horší. Existuje nějaká knihovna přímo pro Qt, ale poté, co jsem si prošel dokumentaci, tak se zdálo, že to není tak úplně to, co bych potřeboval - chtěl jsem asynchronní příjem dat (signál - callback), což Linux podporuje naprosto bez problémů a ve Windows to (podle nejednoho zdroje) vůbec nejde.

[Pavel Vymetálek]

Ve win na to mám právě spuštěné druhé vlákno, které hlídá sériák a když se něco objeví v přijímacím bufferu, tak o tom dá vědět hlavnímu programu...

[trekker.dk]

Podle toho, co jsem se kde dočetl a doslechl, je tohle v podstatě nejlepší řešení. Jenže se mi to nechce dělat, takže jsem zvolil řešení QTimer a test, jestli něco nepřišlo, každých 100ms. Je to řešení blbé, to uznávám, ale já to programuju pro Linux a ve Windows mi bude stačit, když to bude chodit nějak.

[Radek Miček]

POSIX slouží sám o sobě k multiplatformnímu vývoji. Že je Redmond centrálou blbů, za to ostatní nemůžou.

Mimochodem, Windows volitelně podporují pthready prostřednictvím Interixu.

[KS]

Kdyby byl Redmond centrálou blbů, tak bychom se tu o něm asi nebavili.

[Luboš Doležel (Doli)]

Něco podobného je někdy i vláda a také se tu o ní bavíme.

[pasmen]

To se to v 15 kecá, že jo...

[Luboš Doležel (Doli)]

1) O kom mluvíš? 2) Rozumnější a pochopitelnější reakce by z tvojí strany nebyla?

[pasmen]

Mluvím o tobě (trochu důvtipu..) Ta reakce je vzhledem k tvým výkřikům celkem pochopitelná, nemyslíš?

[Luboš Doležel (Doli)]

Jednak mi patnáct opravdu dávno není a za druhé vzhledem k aférám, kauzám, podvodům a dalším věcem to není moc "výkřik".

[pasmen]

To že už ti není patnáct jsem ale vážně nemohl poznat. Aféry, kauzy, podvody atd. atd. jsou úplně všude. To že je to tady víc na očích je věc jiná. Takže ano, je to výkřik. Toť k vládě. Výkřiky typu Redmond je centrála blbců, to je vtipný. Ty lidi na rozdíl od tebe už něco dokázali, a málo toho není.

[Luboš Doležel (Doli)]

To že je to tady víc na očích je věc jiná.

Vláda je místem, kde takové věci nemají co dělat. Tečka.

Výkřiky typu Redmond je centrála blbců, to je vtipný. Ty lidi na rozdíl od tebe už něco dokázali, a málo toho není.

Dokázali co? Kopírovat nápady skutečně inovativních firem a podvolit si trh. Pro spotřebitele jedno lepší než druhé.

[Käyttäjä 11133]

Ale co je dobré pro spotřebitele je tobě v případě, že si producent jedno. Tobě jde o to, aby byl trh příznivý pro tebe.

[Luboš Doležel (Doli)]

To já chápu. Když někdo vykrade obchod, tak je to pro něj taky příznivé. I tak o něm ale nebudu mluvit hezky.

[pasmen]

V lékeřství nebo školství se dějí věci úplně stejné. Tam mají co dělat? Právě tam by neměli... Je to všude tak to nekonkretizuj tam kde to není vhodné prosímtě.

IMHO okopírovat a implementovat nápad v closed-source světe je daleko složitější než v open-source světe. Takže jejich invenci bych neshazoval. To s podvolením trhu, no, to je pravda, ale je to komerční subjekt, tak to prostě chodí, buď vládneš a nebo tě někdo ovládá a sežere.

[Luboš Doležel (Doli)]

Nic jsem nekonkretizoval, začalo to tím, že jsem uvedl příklad.

To s podvolením trhu, no, to je pravda, ale je to komerční subjekt, tak to prostě chodí, buď vládneš a nebo tě někdo ovládá a sežere.

Není to tak černobílé.

[pasmen]

Uvedl jsi příklad, já ti dokážu uvést protipříklad. Je nesmyslné obořovat se výhradně proti jedné skupině a ignorovat při tom stejné jednání všude jinde.

Je to přesně takhle černobílé, alespoň v dnešní době. Každý tvůj zisk jde na úkor ztrát konkurence. Ty máš buď možnost se s konkurencí spojit ve prospěch obou, nebo chtě nechtě budete v konkurenčním boji. A když jde o prachy tak to moc čistý boj není. A nebo mě pouč odborníku. Zatím jsi řekl pouze to, že to není černobílé. Něco konkrétního by bylo?

[Luboš Doležel (Doli)]

buď vládneš a nebo tě někdo ovládá a sežere.

Kdyby tohle byla pravda, tak je v každém odvětví jen jedna solidní firma.

[pasmen]

V limitě věků to tak nepochybně dopadne

[Michal Kubeček]

Neřízený živelný trh "bez přívlastků" skutečně má tendenci nahrávat vzniku monopolů, které nakonec trh a tím i pokrok zadusí. Podle mne to ale neznamená, že bychom si měli říct "tak je holt má být"; naopak, považuji to za jeden z argumentů, proč je určitá míra regulace nutná. Můžeme se samozřejmě přít o to, jak velká ta míra regulace má být, ale nechat trh úplně neregulovatelný vede ke katastrofě.

[pasmen]

S tím souhlasím. Co já říkám je to, že společnosti mají tendenci tímto způsobem fungovat. Trh je svým způsobem džungle, kde slabý zahyne a silný se stane ještě silnějším.

[trekker.dk]

Uvedl jsi příklad, já ti dokážu uvést protipříklad. Je nesmyslné obořovat se výhradně proti jedné skupině a ignorovat při tom stejné jednání všude jinde.

Co to prosímtě meleš? Doli na začátku řekl "něco podobného je i vláda", takže se zjevně neobořuje proti výhradně jedné skupině (MS) ani výhradně proti dvěma skupinám (MS a vláda), ale proti tolika skupinám, proti kterým má výhrady.

Ty máš buď možnost se s konkurencí spojit ve prospěch obou, nebo chtě nechtě budete v konkurenčním boji.

A nebo konkurenci něco okopírovat, pak se s ní soudit (MS na to má, konkurence ne) a pak ji finančně vyčerpanou koupit i s programátorama, aby zalepili chyby, které do produktu MS během kopírování naflákal. Teď jsem si ale nas*al do vlastního hnízda, protože tohle tvrzení vlastně popírá, že by MS neměl vlastní invenci. Má, vynalezl tenhle postup.

A když jde o prachy tak to moc čistý boj není.

A protože tvrdíme, že nic není černobílé, tak jsou různé stupně nečistoty toho boje. A MS je na špici (podplácení, FUDy, soudy... zapomněl jsem na něco?)

[pasmen]

Vzhledem k tomu, že řečené praktiky se užívají vážně všude, měl by tedy vyjmenovat všechny, jak tvrdíš, proti kterým má výhrady. Pokud tak neučiní, vypadá to, jako by měl výhrady právě jen kvůli vyjmenovaným.

Myslíš, že MS měl od začátku $$ na to, aby se soudil s konkurencí? Znáš něco o historii té firmy a situaci v době, kdy firmy jako MS a Apple začínaly? MS (tenkrát potažmo sám velký vůdce) prostě chytře využil všechny výhody, které mu doba poskytla. Doporučuju např. film Piráti ze Sillicon Valley.

Hmm, máš například o uplácení ze strany MS nějaký hmatatelný důkaz? Nebe jen papouškuješ oblíbenou historku?

[trekker.dk]

Hmm, máš například o uplácení ze strany MS nějaký hmatatelný důkaz? Nebe jen papouškuješ oblíbenou historku?

Projdi si staré zprávičky ohledně schvalování OOXML. Mám pocit, že ve Švédsku se podplácení provalilo.

[trekker.dk]

Ehm, respektive takhle - podplácení se někdo provalilo, mám ten pocit, že to bylo ve Švédsku.

[pasmen]

Odkaz mi najdi ty, ty tvrdíš že máš důkaz o uplácení. Jinak to vážně bude vypadat dost trapně... To už jsi mi rovnou mohl říct, ať si to někde vygooglím

[trekker.dk]

Taktika "vyčerpej oponenta tím, že bude hledat odkazy o věcech, o kterých si je jistý", ti nevyjde. Kašlu ti na to, pokud chceš, zůstaň si v nevědomosti.

[trekker.dk]

Beru zpět. Nenašel jsem sice tu zprávičku, ale Google našel tohle

Samotný průběh hlasování nelze nazvat jinak než fraškou. Ve Švédsku bylo ještě pár dní před hlasováním jasné, že norma s drtivým výsledkem neprojde. V den hlasování se ovšem dostavila cca 20 firem, partnerů Microsoftu, každá zaplatila několik tisíc dollarů za hlasovací právo, a OOXML bylo schváleno 20 hlasy. Proti bylo 6, a 4 hlasující raději urychleně opustili jednací sál, aby jejich jméno nebylo spojeno s touto fraškou. Následně se provalilo, že Microsoft zatlačil na své partnery a slíbil jim různé výhody, pokud si zakoupí hlasovací právo a budou hlasovat pro něj. Microsoft se následně přiznal, a Švédská organizace dodatečně zneplatnila svůj hlas pro hrubé porušení podmínek hlasování. Podobné "komedie" se odehrály v Maďarsku a Itálii, které rovněž neodešlou do ISO své hlasy a zdrží se hlasování.

http://www.ddworld.cz/windows/standardizace-microsoft-ooxml-nefalsovana-fraska-5.html

[pasmen]

Pokud jsem to správně pochopil, nejedná se o úplatek, ale o nefér a nemorální jednání. Je tak?

[trekker.dk]

Takže teď, když jsem ti ukázal jasný a konkrétní případ úplatku, tak se pokusíš tvrdit, že to úplatek nebyl, protože Microsoft jim nedal peníze... abych pravdu řekl, tak jsem to od tebe čekal.

[Heron]

Pánové já vám do toho nechci nějak vstupovat, vystačíte si sami, ale zprávičku někde na webu neberete jako důkaz čehokoliv, že ne?

[Luboš Doležel (Doli)]

Microsoft to potvrdil, takže konspirace se nekoná.

[Heron]

To jsou holky šikovný.

[trekker.dk]

Takže to není pravda, dokud tu samou informaci nenajdu na webu Microsoftu a pokud možno ještě nedokážu, že to tam dal MS a ne nějaký cracker.

Nebo i to je málo a mám sehnat ústřižek papírových novin a poslat ti ho poštou? Furt málo? Co videozáznam? Taky málo? No pak už zbývá jedině vynaleznout stroj času a vzít tě do minulosti, aby ses podíval sám.

[Heron]

No já jsem to myslel obecně. U vzdělaných lidí (a na abclinuxu zvlášť) bych čekal znalosti webové prostředí. Zkrátka na web může kdokoliv napsat cokoliv za jakýmkoliv účelem a bez jakékoliv odpovědnosti. Na základě tohoto dělat nějaké závěry mi přijde minimálně podivné. Ale tak já jsem druhé extrém, já nevěřím v podsttaě ničemu.

[trekker.dk]

U vzdělaných lidí (a na abclinuxu zvlášť) bych čekal znalosti webové prostředí. Zkrátka na web může kdokoliv napsat cokoliv za jakýmkoliv účelem a bez jakékoliv odpovědnosti.

Což to víme - nicméně zrovna tenhle případ se omílal několikrát přímo tady, dokonce včetně té informace, že to MS přiznal... akorát ten ddworld byl první odkaz, který jsem našel,další byl na lživě a dál se mi hledat nechtělo.

[pasmen]

Lol, teď jsi mě vážně pobavil. Dokážeš snad podpořit svá obvinění ne? Pokud ne, pak je to právě jen trapné obvinění.

[Käyttäjä 11133]

Jenže ten kdo podvádí není většinou blbec, ale naopak člověk(firma), který(á) si dovede dobře spočítat, že mu (jí) to vyplatí.

[Luboš Doležel (Doli)]

Zamýšlený význam jsem vysvětloval tady.

[Ondrej 'SanTiago' Zajicek]

Nevim, přijde mi lepší dělat programy rovnou jako multiplatformní, když tomu nic nebrání.

No myslim, ze pouziti te knihovny z hlediska multiplatformovosti neni zas tak velka vyhra. Proste namisto relativne standardniho rozhrani (pthreads) by tvuj program vyzadoval rozhrani nejake vice ci mene obskurni multiplatformni knihovny. Treba to ITBB jsem ani nenasel v Debianu, takze bud spatne hledam, nebo jde o znacne obskurni knihovnu, ktera na prevazne casti Linuxovych systemu neni nainstalovana. A mit takovou knihovnu v zavislostech je otrava. To uz by bylo lepsi se podivat po knihovne implementujici pthreads pro ruzne platformy.

Kdyz se objevi nova platforma, tak bych cekal, ze pro ni spis nekdo implememntuje pthreads, nez nejakou obskurni knihovnu.

[David Watzke]

Nevim, jsou pthreads dostatečně multiplatformní? Třeba jednou budeš používat nějaký neposixový operační systém, co můžeš vědět.

No, zatím bych se chtěl naučit s pthreads (chci psát pro Linux/Unix) a pokud to někdy budu potřebovat, naučím se holt jiný. QThread bude asi následovat.

[thingie]

No, jedna věc jsou nějaké asynchronní srandy, aby třeba neviselo někde GUI, druhá skutečně problémy paralelizovat a využít pro jednu úlohu více procesorů. To je jakože docela těžký.

[alblaho]

No hlavně je to vlastnost dané úlohy. Viz. http://en.wikipedia.org/wiki/Amdahl's_law

Ale na potrápení se synchronizací ty asynchronní srandy bohatě stačí.

[Jirka P]

No hlavně je to vlastnost dané úlohy. Viz. http://en.wikipedia.org/wiki/Amdahl's_law

Teda podpořit tvrzení o "vlastnostech úlohy" odkazem na tvrzení, kde se o vlastnostech úlohy ani nemluví, to je teda síla. Kdyžtak http://en.wikipedia.org/wiki/P-complete.

[alblaho]

Tak podle tebe to, do jaké míry je daná úloha paralelizovatelná _není_ vlastnost dané úlohy?

[Jirka P]

Podle mě to, do jaké míry je daná úloha paralelizovatelná _není_ vlastnost. Jak bys to chtěl rozumně definovat?

Samozřejmě, můžeme se bavit o (ne)existenci algoritmů na řešení dané úlohy danými prostředky (tedy i paralelním počítačem), což je bezesporu vlastností té úlohy. Ale o tom můj příspěvek vůbec nebyl.

Narážel jsem na to, že Amdahlův zákon nemluví o nějakých ůlohách, ale o zrychlování programů, a to ještě za dost specifických podmínek (který program se zkládá z částí které vůbec paralelizovat nejdou a z částí, které na k procesorech poběží k-krát rychleji, navíc tyto části musí běžet sériově za sebou ... ?)

Navíc to s těmi špatně paralelizovatelnými ůlohami není tak strašné, většinou jde o nějaké zpracování textu nebo simulaci stavových strojů. Dnešní stav je způsoben spíš tím, že není potřeba nějak moc paralelizovat, blbě se to programuje a ještě hůř ladí.

[|🇵🇸]

OpenMP?

[Käyttäjä 11133]

On chce psát vícevláknové aplikace, ne aplikace pro cluster

[michich]

OpenMP není pro clustery, ale právě pro paralelní programování se sdílenou pamětí (čili thready). Byl jsem na přednášce Ulricha Dreppera, kde nás učil jak zacházet s pthreads. Na konci prohlásil, že by byl nejraději, kdybychom pthreads používali co nejméně a raději využívali OpenMP.

[Käyttäjä 11133]

Myslím si, že pro pár vláken je OpenMP overkill.

[michich]

Právě že to vůbec není overkill, naopak. Krása OpenMP je v tom, že je to jednodušší než piplání se s pthreads. V céčkovém kódu se jen přidají #pragma typu "tenhle cyklus můžeš paralelizovat", "tyhlety funkce můžeš volat paralelně"... A kompiler už to zařídí.

[Käyttäjä 11133]

OpenMP není pro clustery, ale právě pro paralelní programování se sdílenou pamětí

Jinak to se snad nějak vylučuje?

[michich]

Myslím, že si pleteš OpenMP s MPI.

[bubak]

Mozna se mrkni na javu. Concurrent utils, fork and join, Foxtrot, SwingWorker... Da se v tom delat aniz se clovek zblazni.

[Heron]

Napsal jsi to za mě .

[Ladicek]

Plus milión, java.util.concurrent je velmi chladné a vládnoucí (a já sprostý plagiátor).

[Josef Kufner]

Od dokonalosti to však dělí minimálně jedna věc: Java.

[Kyosuke]

Jestli "chladné a vládnoucí" znamená "když si vyjedu interfejs z tiskárny, rozmáčkne to i slona", pak nepochybně ano.

[Ladicek]

Tobě se nelíbí, že inherentní součástí té knihovny je i pořádná dokumentace? A podle mne by to rozmáčklo sotva laboratorní krysu, zas bych to nepřeháněl. Je to prostě šikovně navržená a kvalitně implementovaná knihovna pro paralelismus tak, jak se dneska obvykle provozuje (zámky, jednoduché atomické operace, thread-safe datové struktury), určitě takové existují i pro to C++.

[|🇵🇸]

wxWidgets umí více vláken, ale asi chceš Qt, že?

[David Watzke]

Když už GUI, tak určitě Qt 4 (a zároveň určitě ne wxWidgets).

[|🇵🇸]

Co máš proti wxWidgets?

[springer]

myslim, ze to byl pan Ponkrac na rootu, kde rekl, ze by ty "vlaknare" nejradeji kopal do hlavy. (tedy tak nejak). Musim rici, ze s nim v tomto souhlasim, vlakna se precenuji. Nejjistejsi zpusob, jak programovat vicevlaknove je to nepouzivat.

[David Watzke]

To je pěknej nesmysl. Určitě je hloupost používat vlákna zbytečně, ale když něco může využít víc procesorů a tím pádem pracovat několikanásobně rychleji, tak proč to tak nenapsat?

[thingie]

To by bylo pěkný, kdyby to byla taková sranda jak to tady říkáš.

[Jary]

On tady řiká, že je to sranda?

[David Watzke]

Neříká, on si uvědomuje, že to sranda rozhodně není. Když už si s tím někdo dá tu práci (třeba vývojáře enkodéru x264 fakt obdivuju), proč ho kopat do hlavy? To je fakt kyd roku...

[Heron]

No je otázkou, zda pan Ponkrác myslel zrovna vývojáře typu x264. Tipuji, že myslel zcela jinou skupinu "vývojářů".

[alblaho]

Přesně. Jde o to, že použitím více vláken se daná implementace _řádově_ zesložiťuje. Časová úspora vícevláknového výpočtu jen málokdy stojí za tu komplexnost, kterou to přinese.

x264 je úloha, kde se to vyplatí, neb je to jasně definované chroustání dat.

[Kyosuke]

Starý, ale dobrý: http://home.pacbell.net/ouster/threads.pdf. Osobně mi přijde, že nejlepší je tyhle věci nejen vestavět do knihoven, ale rovnou je hodit do jazyka, s rozumnými primitivními operacemi. Sice to člověka trošku omezí, ale pak to nemusí tolik ladit. Myslím, že STM, Haskell, Erlang - možná i Ada - ukazují cestu k programátorskému spasení. x264 zpracovává víceméně hafo nezávislých bloků, takže vlákýnka nemusejí sdílet moc read/write stavu.

[thingie]

Očividně si to myslí.

Já bych s tím tvrzením, že snažit se psát vícevláknové aplikace s cílem je zrychlit a využít víc procesorů nemá cenu, docela souhlasil. Zisk (bude-li jaký, ne jenom tuna chyb a pádů navíc) za to s*aní nestojí. V oblasti aplikací co může DW chtít psát určitě.

[Jary]

Prosím vysvětlit, jinak bych tohle musel považoval za snůšku kydů.

[trekker.dk]

Nejjistejsi zpusob, jak programovat vicevlaknove je to nepouzivat.

Přesně tak, přece nebudeme procesor přetěžovat současnou prací všech čtyř jader naráz...

Co já bych dal za to, aby mdX_raid5 uměl počítat paritu na obou jádrech naráz a já neměl rychlost zápisu jenom 30MB/s.

[deda.jabko]

nechce se mi verit, ze bych s panem P. souhlasil... ale v tomto ma pravdu. nejlepsi zpusob, jak zachazet s vlakny je je nepouzivat. je to neco jak programovani v assembleru... obcas to prinese urcite zlepseni... ale za vcelku vyraznou cenu. proto bych doporucil se vlaknum vyhnout, dokud je opravdu nebudete potrebovat ....a mozna se do te doby objevi rozumne paralelizacni knihovny nebo jazyky, ktere budou umet vic nez jen tupe zamykat jednotlive zdroje... ;-]

[Jary]

Přemýšlel jsem a taky se mi nechtělo věřit, že jsem začínal souhlasit. Ale potom mě napadlo, že pokud vývoj půjde cestou nezvyšování frekvence, ale zvyšování počtu jader, budou multithreadové programy in.

Samozřejmě, že se nevyplatí dělat multithreadově něco, co se nedá dobře paralelizovat. To by se však mělo zvážit před tím, než se něco začne dělat multithreadově. Stejnětak by se mělo zvážit, jestli nemůžu zlepšit algoritmus. Dělat něco neefektivně na mnoha CPU, to zní děsivě.

[Käyttäjä 11133]

Mnohem děsivěji zní "Dělat něco neefektivně na jednom CPU" Alespoň co se týče promarněného času.

[David Jaša]

To první zní děsivě co se týče promarněné energie.

[depka]

pracovat s vice vlakny zdaleka neznamena pracovat s vice procesory

[Ladicek]

To je velmi dobrý postřeh, více vláken na jednom procesoru je úplně jiná situace než více vláken na více procesorech (minimálně kvůli koherenci per-procesor keší). V takové situaci se začíná teprve projevovat opravdová zrádnost snah o paralelismus, ideálně samozřejmě pod reálnou zátěží, což je věc, která se skvěle simuluje

[Kyosuke]

Zrádnost? Jaká zrádnost? Erlang přestal fungovat?

[Ladicek]

Erlang doufám pořád funguje tak, jak fungoval už léta, protože po něm sám občas pokukuju (s čistě teoretickými úmysly). Ale myslím, že víš velmi dobře, že jsem měl na mysli běžné programátorské platformy typu třeba to C++ (nebo Java, samozřejmě).

Naprosto souhlasím s tím, o čem mluvíš níže, že je potřeba nějaká vysokoúrovňová paralelizační primitiva zabudovat přímo do jazyků (STM, erlangovské posílání zpráv, whatever, nejsem v tom moc kovaný). Mimochodem jedna experimentální implementace STM pro Javu je přímo od Sunu

[Let_Me_Be]

Jak na kterem operacnim systemu. Treba takovy Solaris s tim problem nema (pro Windows existuje nejaky extension).

[Filip Jirsák]

Myslím, že na programovacím jazyce nebo knihovně až tak nezáleží (pokud tedy není pouze jednovláknová, nebo se naopak o zamykání nestará komplet sama). Spíš je potřeba naučit se myslet na to, že pokaždé, když pracuju s nějakými daty, která mohou být přístupná z více míst, musím si hlídat, co se stane, když se mi najednou uprostřed mého kódu změní data, nad kterými ten kód pracuje. Další úroveň je pak naučit se v takovém kódu pracovat se zámky – to znamená použít zámek všude tam, kde je potřeba, ale zároveň jej nikdy nepoužívat zbytečně. Pak může být ještě užitečné naučit se naprogramovat nějaké základní datové struktury (seznam, mapa) tak, aby byly použitelné ve vícevláknovém prostředí – ale na to už většinou máte nějakou knihovnu.

Na čem si to vyzkoušet – jeden takový klasický případ je dlouhotrvající operace v GUI aplikaci. Ta operace samotná musí běžet v samostatném vlákně, aby se nezablokovalo GUI, a GUI je potřeba nějak aktualizovat, případně umožnit operaci přerušit. Pokud používáte nějaký GUI toolkit, který není pro více vláken navržen (jako třeba Javovský Swing), dobře si na tom procvičíte komunikaci mezi vlákny. Pro zamykání je zase dobrý tréninkový příklad návrhový vzor Jedináček (Singleton) s odloženým (lazy) vytvořením, kdy je potřeba zajistit, aby vznikl jen jeden objekt, ale aby se nemohlo stát, že nějaké vlákno dostane napůl vytvořený objekt.

[alblaho]

To jsem zrovna chtěl napsat. Může sice udělat vícevláknové vyčíslování integrálu, kde se mu to opravdu zrychlí, ale to není typické použití. Typické použití vláken je v gui - vlákno kreslící GUI nesmí lagovat, proto nesmí dělat žádné operace co se můžou zablokovat (náročné výpočty, I/O). Takové operace se musí dělat v pracovním vlákně, které zas ale nesmí šahat na gui.

Takže žádné enkódování a lámání šifer - stačí kvalitní GUI aplikace.

[depka]

Může sice udělat vícevláknové vyčíslování integrálu, kde se mu to opravdu zrychlí

to se mi nezda, kdyz se stejne budou ty vlakna delit o procesorovy cas

[alblaho]

Myslel jsem samozřejmě dnes obvyklou situaci, kdy má počítač víc jader.

[Käyttäjä 11133]

Na dvoujádru? :-p Nebo na mosix clusteru,...

[Michal Kubeček]

Uvědomte si, že vícejádrové procesory už jsou dnes mainstream. A pokud někdo hodlá provádět ve větší míře numerické výpočty, byl by blázen, aby si pořizoval jednojádrový, když dvoujádrové stojí jen o trochu víc a i čtyřjádra už se dají pořídit za relativně lidové ceny.

[depka]

odpoved na vsechny tri: kdyz spustite vicevlaknovy program na viceprocesorove architekture tak to bohuzel neznamena ze ty vlakna pojedou paralerne..., to uz je uplne jina uroven navrhu programu

[Michal Kubeček]

Neznamená to automaticky, že poběží paralelně, ale stejně tak to automaticky neznamená, že se "budou dělit o procesorový čas". Bude to něco mezi tím a bude záležet na programu, čemu to bude blíž. Zrovna v případě úlohy, o které byla řeč v příspěvku, na který jste reagoval, tj. numerického výpočtu integrálu, to bude velmi blízko tomu paralelnímu běhu.

[Michal Kubeček]

Řekl bych, že typické využití je oboje - jak interakticní GUI, tak ty přirozeně paralelizovatelné výpočty. A samozřejmě i řada dalších - třeba síťoví démoni, u kterých se očekává vysoká zátěž.

[alblaho]

Na mém počítači je poměr interaktivních gui aplikací na paralelizovatelné výpočty tak 1000:1

Síťoví démoni sice typicky jsou vícevláknoví (nebo spíš víceprocesoví), ale jednotlivé instance spolu moc nekomunikují.

[Michal Kubeček]

Na mém počítači je poměr interaktivních gui aplikací na paralelizovatelné výpočty tak 1000:1 :-)

Překvapivě existují i počítače, kde je to naopak. :-)

Síťoví démoni sice typicky jsou vícevláknoví (nebo spíš víceprocesoví), ale jednotlivé instance spolu moc nekomunikují.

Jak kdy. Psal jsem jednoho takového, kde mne ani nenapadlo nepoužít thready, protože bych stejně musel většinu datových struktur řešit přes sdílenou paměť.

[xxx]

Takze se naskyta pekna moznost napsat si vlastni thread pool.

[Ladicek]

naučit se naprogramovat nějaké základní datové struktury (seznam, mapa) tak, aby byly použitelné ve vícevláknovém prostředí

Ono jedna věc je naprogramovat takovou strukturu tak, aby byla thread-safe, a druhá věc je, aby byla v paralelním prostředí rozumně výkonná a hlavně škálovatelná. To druhé je předmětem specializovaných vědeckých konferencí, na kterých publikují lidé typu Doug Lea. Když jsem četl, jak je v java.util.concurrent implementován spojový seznam, tak mi vstávaly vlasy hrůzou na hlavě

návrhový vzor Jedináček (Singleton) s odloženým (lazy) vytvořením, kdy je potřeba zajistit, aby vznikl jen jeden objekt, ale aby se nemohlo stát, že nějaké vlákno dostane napůl vytvořený objekt

To je vůbec zajímavá problematika. Double-checked locking? Ono se to pak komplikuje požadavky reálného světa, kdy je třeba potřeba singleton občas reinicializovat apod., a většinou se dojde k tomu, že požadavek na jednu jedinou instanci je vlastně neopodstatněný, a že pokud už stačí jeden jediný objekt, pak tři nebo čtyři inicializace, z nichž se posléze po většinu času bude používat jenom jedna, vlastně ničemu nevadí. A vůbec, http://tech.puredanger.com/2007/07/03/pattern-hate-singleton/

Nicméně, souhlasím, to všechno je pro učení dobré. Ale je těžké si ověřit, že jsem to udělal správně, a je těžké pak nepodlehnout pokušení takový vlastní výtvor používat

[podlesh]

To druhé je předmětem specializovaných vědeckých konferencí, na kterých publikují lidé typu Doug Lea. Když jsem četl, jak je v java.util.concurrent implementován spojový seznam, tak mi vstávaly vlasy hrůzou na hlavě

Náhodou, doporučuji si přečíst ten odkazovaný dokument, případně další články dvojice Michale&Scott. Také jsem si přečetl něco o teoretické konstrukci použité pro dokázání korektnosti (Linearizability, Herlihy&Wing). Moc zajímavé čtení.

Každopádně platí, že nemá smysl vymýšlet nějakou vlastní thread-safe datovou strukturu.

[Kyosuke]

Já myslím, že stačí počkat, až se javisté smíří s existencí STM, Concurrent Haskellu a Erlangu a vzdají pokusy o vláknový paralelismus složitých algoritmů na glorifikovaném Turingově stroji.

[Ladicek]

na glorifikovaném Turingově stroji

Myslím, že se dokazuje výpočetní ekvivalence Turingáče a lambda kalkulu, takže za glorifikovaný Turingův stroj bych klidně mohl označit i Lisp :-P

[Kyosuke]

Formálně jsou ekvivalentní. Ale optimalizující kompilátor je v obou případech nucen dělat rozdílné množství práce. Jen si vezmi dva následující kusy kódu:

(map (lambda (x)
        (* 2 x))
     seznam)

int * 
vrat_dvojnasobek(int *pole, int delka)
{
    int *vysledek = malloc(sizeof(int)*delka);
    int i;
    for(i=0; i<delka; i++)
        vysledek[i] = pole[i]*2;
    return vysledek;
}

Kdybys byl kompilátor, v kterém případě bys rychleji (s menším množstvím výpočetních cyklů strávených přemýšlením nad jednotkou kódu) poznal, že dotyčný kus kódu vrací složenou datovou strukturu téže délky, jakou přijímá na vstupu, a že každý prvek výstupu je "čistou funkcí" (bez vedlejších účinků) vstupu, takže je možno v případě (kdyby byl výpočet výstupního prvku o složitější a trval o dost déle, než jedna iterace traverzování té struktury) rozhodit výpočet na víc procesorů na úrovni jazyka? Java je v tomhle třeba o něco dále, než Cčko, ale taky pořád žádná sláva, vlastně skoro vůbec žádná sláva. Aspoň že ty ukazatele jsou fuč.

Člověk sice třeba u Haskellu musí dost změnit způsob přemýčlení, ale myslím, že se nám za třicet let budou haskellisté smát, až se budou za břicho popadat, protože jim ty STM programy a automaticky paralelizované algoritmy na šedesátičtyřjádrových noteboocích s procesory Intel Core 7 Sexagintaquattuor prostě budou běhat mnohem líp, než jak dobře bude běžet JBoss 23.1 na Javě 17. Na druhou stranu je možné, se Haskell v té době bude jmenovat Java NG (jako Next Generation), nebo že Java 17 se sice bude jmenovat Java, ale sémanticky to bude Haskell. ("Přiřazení jsme zrušili, mutable data nejsou dobrý nápad, zvláště se zamykáním na 64core procesorech, a navíc jsme ten GC zase vylepšili, takže mašině to tolik nevadí, a koukejte si zvyknout, holomci." )

[Kyosuke]

Ehm...v případě potřeby (kdyby byl výpočet výstupního prvku o něco složitější a trval o dost déle, než jedna iterace traverzování té struktury)...

[pasmen]

lol

[Kyosuke]

Jaký "lol"? Věcná připomínka by nebyla?

[Ladicek]

Ale jo, já s tím souhlasím. Implicitně paralelizovat Céčko nebo Javu je určitě práce pro vraha (ne že by to u čistě funkcionálních jazyků byla sranda), ostatně i ta explicitní ( ) paralelizace v těchhle jazycích není zrovna triviální. Takže se na to dělají knihovny (java.util.concurrent, pro Javu 7 rozšíření Fork-Join) i nové jazyky (X10). Že by se z Javy (jazyka) stal Haskell si nemyslím, ale je dost možné, že na Javě (platformě) bude za těch třicet let nějaká podobná potvornost dominovat.

Nebo se může stát, že někdo někde ty vrahy sežene, protože bušiče kódu v Javě vychováš snadno, ale bušiče kódu v Haskellu? Pochybuju. To spíš v tom Lispu, který nemá s přiřazením ani vedlejšími efekty problém Nebo v tom Erlangu, no.

[deda.jabko]

paralelni lisp... jako bych to uz nekde videl... ;-] skoda, ze vetsina rozumnych veci tykajicich paralelniho lispovani pochazi z konce 80. a zacatku 90. let, takze je zatizena podminkama tehdejsiho hardwaru, takze je vlastne k nicemu... a soucasne nejvetsi paralelizacni pokroky se delaji na haskellu.

taky si nemyslim, ze by se z javy stal haskell... ale kdyz vidim, jak se do javy a c# pridavaji dalsi a dalsi prvky z funkcionalnich jazyku zacinam byt optimisticky. spis bych to videl, ze bude potreba vyvinout jazyky, ktere se vykaslou na nejake zamykani a podobne skopiciny a budou obsahovat paralelizacni primitiva na vyssi urovni... jako treba ten zmineny ,,map''.

[Ladicek]

Jasně, map a reduce… moment, to už přece u Googlu mají… moment, vždyť tam to přece mají v C++

[podlesh]

Já myslím, že stačí počkat, až se javisté smíří s existencí STM, Concurrent Haskellu a Erlangu a vzdají pokusy o vláknový paralelismus složitých algoritmů na glorifikovaném Turingově stroji.

Složité algoritmy a Java? Kde kupuješ matroš?

A vůbec, celá tato diskuse mi připadne absurdní. Ten kdo implementuje nějaké výpočty snad ví co dělá a dokáže posoudit různé prostředky (no, alespoň předpokládám).

Ovšem drtivá většina všech programů jsou buď GUI klikátka (paralelismus slouží k tomu, aby se pěkně překreslovala okénka i při čekání na I/O) a nebo aplikace přehazující hromady dat sem a tam (kde paralelizace slouží k tomu, aby se dosáhlo co největší propustnosti při čekání na I/O).

Jo a potom ještě počítačové hry, uznávám.

[Filip Jirsák]

Datové struktury pro vícevláknová prostředí jsem myslel právě takové, které budou nejen thread-safe, ale budou se chovat nějak „rozumně“. Což nemusí být jen škálovatelnost. Existují i různé speciální případy – nějaká datová struktura se může nejprve jen vytvořit a naplnit, a pak už se z ní jenom čte – pak je zbytečné při každém čtení kontrolovat zámek. Nebo poměr čtení k zápisu je výrazně ve prospěch čtení a nevadí, že ihned po zapsání nemusí být data dostupná pro čtení jinému vláknu – pak je zase možné udělat zápis složitější a náročnější na paměť s tím, že čtení bude opět bez kontroly zámku. To asi není chování, které by bylo rozumné a škálovatelné obecně, ale někdy se hodí.

Většinou je požadavek na jedinou instanci neopodstatněný, ale někdy je přeci jen potřeba – třeba pro nějaký čítač, který má pro každou položku vytvořit unikátní identifikátor. Ale pokud jde o Javu 1.5 a vyšší, a identifikátor může být číslo, stačí použít AtomicInteger nebo AtomicLong. Navíc pokud nevadí, že se ta jediná instance vytvoří hned při vytvoření třídy, dá se opravdový Jedináček zařídit v Javě snadno.

Ale je těžké si ověřit, že jsem to udělal správně, a je těžké pak nepodlehnout pokušení takový vlastní výtvor používat

To je asi nejtěžší na vícevláknovém programování. Pokud je nějaká chyba v synchronizaci, projeví se jenom občas a to ještě zpravidle někde úplně jinde, než kde je problém. A ani pak nestačí program ladit v debuggeru, protože ten úplně změní chování aplikace a k problému zpravidla nedojde. Takže většinou je jediná možnost – přečíst si příslušný zdrojový kód, pochopit ho a pak si logicky zdůvodnit, jestli ten kód je správně nebo špatně. Úplně jak za starých časů, kdy žádné debuggery neexistovaly.

[Ladicek]

Datové struktury pro vícevláknová prostředí jsem myslel právě takové, které budou nejen thread-safe, ale budou se chovat nějak „rozumně“. Což nemusí být jen škálovatelnost. Existují i různé speciální případy – nějaká datová struktura se může nejprve jen vytvořit a naplnit, a pak už se z ní jenom čte – pak je zbytečné při každém čtení kontrolovat zámek. Nebo poměr čtení k zápisu je výrazně ve prospěch čtení a nevadí, že ihned po zapsání nemusí být data dostupná pro čtení jinému vláknu – pak je zase možné udělat zápis složitější a náročnější na paměť s tím, že čtení bude opět bez kontroly zámku. To asi není chování, které by bylo rozumné a škálovatelné obecně, ale někdy se hodí.

Myslel jsem škálovatelnost co do počtu současně běžících (přistupujících k dané struktuře) vláken, což myslím popisuje i ty zvláštní případy. Ale jasně, požadavky jsou různé. Jinak ty zvrhlosti, které vymýšlejí šílení vědci, se právě týkají např. bezpečného souběžného přístupu k datové struktuře bez zamykání (třeba v Javě se dá s výhodou využít zápisu do volatile proměnné pro synchronizaci viditelnosti, brr ).

To je asi nejtěžší na vícevláknovém programování. Pokud je nějaká chyba v synchronizaci, projeví se jenom občas a to ještě zpravidle někde úplně jinde, než kde je problém. A ani pak nestačí program ladit v debuggeru, protože ten úplně změní chování aplikace a k problému zpravidla nedojde. Takže většinou je jediná možnost – přečíst si příslušný zdrojový kód, pochopit ho a pak si logicky zdůvodnit, jestli ten kód je správně nebo špatně. Úplně jak za starých časů, kdy žádné debuggery neexistovaly.

Za starých časů si člověk pořád ještě mohl udělat aspoň ladicí výpis

[Kyosuke]

Jinak ty zvrhlosti, které vymýšlejí šílení vědci, se právě týkají např. bezpečného souběžného přístupu k datové struktuře bez zamykání

Myslíš Okasakiho? Dneska je to ještě trošku scifi, tedy aspoň pro velké korporace , ale některým lidem to zjevně funguje úplně normálně.

[Ladicek]

To vypadá zajímavě, ale pochopitelně to neznám Měl jsem na mysli něco trochu přízemnějšího

[Let_Me_Be]

Prosimte, vykasli se na pThread, to je ztrata casu, radeji se podivej na tohle: http://www.boost.org/doc/libs/1_35_0/doc/html/thread.html

Melo by to cca. odpovidat podobe v jake se to bude vyskytovat v novem C++ standardu.

[David Watzke]

Podívám se na to, díky.

[Kyosuke]

Nemyslím, že pthreads jsou ztráta času. Je to jen ztráta času pro ty, co zrovna nepíší dobré knihovny pro programátory aplikací. BTW, kdy už ten standard bude? Aby nás Microsoft se systémovými jazyky nepředehnal. Nepřejmenovali to nedávno na C++ 201x?

[elviin]

Konecne nekdo odpovedel k veci. Boost je jedna ze zakladnich znalosti programatora v C++. Nez to ale mnozi pochopi, budou stale dokola vytvaret nove a nove kolo. Je to asi zpusobeny tim, ze se u nas asi dostatecne necte anglosaska literatura a z toho plyne malej prehled. Do te doby, nez si u nas firmy osvoji boost, tak budou delat "multiplatformni" framework v C++ c. 1324 atd. Uvazoval jsem o serialu o Boostu, ale nenajdu si cas. Jen poznamka ke Qt: v pripade qt threadu a signalu, neni mozny je michat se signaly/thready z boostu.

[elviin]

Jinak jeste k tem threadum. Pridam knihovnu Intel ® Threading Building Blocks.

[Chocolate Bear]

Bude trapné, když zmíním, že o ITBB i o boostu mluví hned třetí komentář? Jo, bude :-P

[elviin]

Mate pravdu. Je zvlastni, ze jsem to pres Ctrl+F nenasel:)

[Ondrej 'SanTiago' Zajicek]

Dany komentar ITBB nezminuje pod jmenem, pouze na nej odkazuje (a to jeste tak, ze z popisku odkazu nelze poznat, kam se to vlastne odkazuje). Neni divu, ze nahodny ctenar z nej nepochopi, ze se odkazuje na ITBB.

[YYY]

man vfork

[YYY]

I kdyz se nejedna o vytvoreni threadu, ale je to podobne. Rodicovsky a detsky proces maji sdilenou pamet.

[Michal Kubeček]

Myslíte tuhle část? :-)

It is rather unfortunate that Linux revived this specter from the past. The BSD man page states: "This system call will be eliminated when proper system sharing mechanisms are implemented. Users should not depend on the memory sharing semantics of vfork() as it will, in that case, be made synonymous to fork(2)."

[michich]

Šmarjá, jen to ne. Jediné rozumné, co se dá udělat po vfork(), je okamžitě exec().

[YYY]

Samozrejme vim, ze pthread rulez.. ;) Ale je to tezsi...

[michich]

Ale vfork(2) slouží úplně k jinému účelu. Vůbec netuším, jak bys pomocí něj chtěl udělat něco jako thready. Chování procesu vytvořeného vforkem je definované pouze tehdy, pokud ten proces okamžitě:

a) skončí voláním _exit(2), nebo

b) začne vykonávat jiný program voláním execve(2).

Nic jiného ten proces udělat nesmí. Není definováno, jestli je rodič po vforku zablokován. Není definováno, co se stane, když potomek zapíše do sdílených dat nebo když zavolá libovolnou funkci.