Názory k článku
Python: skriptování ve více vláknech

Ale kdepak. Modul multiprocessing existoval samostatně už pro starší verze Pythonu pod názvem processing: http://pypi.python.org/pypi/processing . Do 2.6 a 3.0 ho prostě jenom zařadili.

Zil jsem (asi v naivni) predstave, ze clanek by mel vychazet hlavne z autorovych zkusenosti, manual si muze precist kazdy...

Ale coz, priste to snad alespon vyzkousite. ;-)

k tomuto se pripojuji, hrat si s necim cely vikend a pak o tom napsat clanek neni dle meho soudu ta spravna cesta, praci jen precist si co to jsou vlakna (obecne) muze clovek na hodne mistech kdyz tohle chape, neni problem se podivat na konkretni implementaci v danem jazyce

No tak koukam, ze nekdy je lepsi nevedet :))). Threading pouzivam v Pythonu nekolik let a nikdy sem nenarazil na zadnej problem s nakym GILem :). Normalne mi GUI aplikace reaguje i kdyz v jinym threadu nacita data, normalne se mi script pripoji pres telnet na 100 masin najednou a vystup z nich zpracuje. Asi neco delam spatne :). Pravda vubec nepouzivam locky. Data prenasim mezi threadama pred queue...

Ano, je rozdíl mezi výpočtem konkurenčním a paralelním. Navíc bych dodal, že GIL nedrží ta vlákna po celou dobu, ale pouze po dobu, kdy potřebují přistupovat k pythonovským objektům. To znamená, že výpočet ve skutečnosti může běžet paralelně, ale to paralelní zrychlení je omezené v závislosti na tom, co jednotlivá vlákna skutečně dělají.

OK, to dava smysl. Pokud se pres queue pokusim prenyst objekt, tak aplikace vytuhne, ale s jednoduchyma promennyma to funguje dobre. Vyuziti vice jader me az tak nezajima, protoze pro narocny vypocty Python tak jako tak neni.

Vy si z root.cz děláte soukromý kurz psaní, ne? Už se zde nelze spolehnout ani na to, že autor vůbec ví, o čem píše...

Vzdyt to bylo jasne od prvnich vet clanku. Vcera jsem se podival na thready v Pythonu a dneska o nich nadsene pisu blbaoly do rootu :-). To rika vse o urovni autora i rootu :-).

Ve Stacklessu je situace lepší v tom, že obsahuje tzv. tasklety (obdoba např. green threads z Javy), které mají minimální režii a stará se o ně přímo Stackless bez účasti OS. Pokud se chceš zbavit GIL, zaměř se na Jython (příp. IronPython).

> No a extremni moznost je napsat si cast programu v C za pouziti Python/C API, kde je mozne odblokovat zamek, pokud se zrovna u vas vykonava ciste Cckovy kod.

Díky za příspěvek, chystal jsem se napsat něco velmi podobného. Ale proč to odemknutí považujete za extrémní možnost? Napsal jsem v Pythonu poměrně rozsáhlou produkční aplikaci, která hodně času stráví v C modulu, který je poměrně izolovaný a do sdílených dat nesahá- s odemknutím nebyl žádný problém, a teprve poté mohly ostatní thready použít druhé jádro na serveru.

Přesto bych doporučoval- pokud je aspoň trochu možné aplikaci napsat jako víceprocesovou (komunikace jen pomocí wait(), pipe(), nebo mmap(.. MAP_SHARED), tak se na vlákna úplně vykašlete, a vesele sys.fork()ujte. Ty moduly pro multithreading se mi nezdají moc kvalitní.

> Bohužel právě na vývojáře aplikací jsou tím kladeny větší nároky.

Je dobré si uvědomit, že ne každý výpočet lze rozumně paralelizovat. Některé úlohy jsou inherentně sekvenční, u jiných je paralelní zrychlení málo výrazné a obecně záleží na objemu dat, které zpracováváme. Existují například algoritmy pro paralelní řazení, ale pro malé pole se to nevyplatí. Více procesorů/jader tedy nemusí znamenat vždycky až takovou výhru.

> Již nestačí přemýšlet nad tím, jak se změní paměť po vykonání nějaké funkce, ale jak se možná změní paměť po vykonání této funkce předtím, případně po té, než naběhne nějaké vlákno.

V mnoha případech by mohl pomoci aktorový model známý např. z Erlangu a Scaly. Ten programátora od podobných problémů uchrání. Viz třeba http://osl.cs.uiuc.edu/parley/

> Občas musí program čekat třeba na disk nebo odpověď nějaké vzdálené služby.

Hlavně je potřeba zajistit odezvu GUI, pokud potřebujeme dlouho chroustat data nebo komunikovat s okolím.

> Během čekání zatím může běžet jiné vlákno nebo rovnou program.

Program nebo proces?

> Lock a RLock jsou více méně totožné, pouze ten druhý můžeme nastavit několikrát.

RLock lze bezpečně použít (získat) opakovaně v jednom threadu, zatímco pokud zavoláme opakovaně v jednom vlákně Lock.acquire() na stejném zámku, dojde k deadlocku. Osobně bych si pod "nastavit několikrát" nic nepředstavil, sorry, ale to bylo poměrně chabé vysvětlení.

> je založen na implementaci vláken v Javě. Tzn. že se ovládá podobně

Podle mě to, že se ovládá podobně neznamená, že je založen na implementaci v Javě, ale to je detail.

> Událost, zpráva, signál

Tři výrazy pro jednu věc v kratičkém článku, to není moc dobré. Pojem "zpráva" bych v tomto kontextu raději vůbec nepoužíval (hodí se spíš do toho aktorového modelu) a zůstal bych u události, když už se ta třída jmenuje Event.

Myslím, že tato problematika by si zasloužila delší článek nebo spíš seriál (chystal jsem se ho napsat, ale klidně ho přenechám autorovi tohoto článku nebo komukoliv jinému; času mám málo). Za zmínku určitě stojí GIL, multiprocessing (což zmiňovali jiní), tasklety ve stacklessu, možná bych zmínil další možnosti typu MPI, snad by se do seriálu hodila i problematika IPC v kombinaci Python + Linux. Mohlo by to být zajímavé.

Pripojim se s pripominkami.
Ted je v clanku formulace
> Lock a RLock jsou více méně totožné, pouze ten druhý můžeme bezpečně použít několikrát.
coz neni o nic lepsi nez bylo driv. Nejde o nasobne pouziti (ostatne bez toho by ani lock nemel smysl) ale o to, ze jeden thread muze mit RLock v danou chvili vicekrat zamknuty bez predchoziho odemknuti a nezasekne se. Mozna jste to tak myslel, ale ja kdybych to nevedel uz z drivejska, tak by mi to po tehle vete jasne nebylo.

Popis kriticke sekce je ponekud zmatecny. Asi by bylo lepsi to seradit nejak takto:
- existuje kriticka sekce (misto, kde neni zadouci mit najednou vice (libovolne) threadu)
- jak se takove misto pozna
- cim se to da resit.
Takhle z toho mam pocit, ze kriticka sekce vznikne, kdyz se neco zamkne, ale neni mi jasne jak poznat, ze je to potreba zamknout.

Mozna bylo zbytecne jit do problematiky tak hluboko, ale kdyz uz, tak by to melo byt poradne. Je spatne nehlidat kriticke sekce, ale jeste horsi je zit v iluzi, ze staci KS obalit zamkem a pritom ani nevedet, jak se pozna kde KS je a jaky je jeji rozsah. Vzhledem k tomu, ze je to clanek pro zacatecniky, tak by urcite bylo dobre tam zminit, ze je to narocne a v clanku jen lehce natuknute tema. Proste aby bylo jasne, ze to neni vsechno, co je potreba vedet ;-)

Kup si stroj s 1GB SRAM, myslím že pak většina programů pojede třeba 10x rychleji aniž by se změnil takt procesoru (prostě by byla celá paměť rychlá jako cache v procesoru).

Jestli umíš udělat procesor líp, tak jim prosimtě poraď, třeba ti dají i nějaké peníze.

Musím říct, že článek se mi vůbec nelíbil. Formulace jsou takové vágní až zavádějící, chybí zmínka o GIL (což je dost zásadní fakt). Prostě je to typický příklad článku, který je napsán někým, kdo problematice moc nerozumí.

Nepřál jsem si zůstat v anonymitě. -- Jan Švec

Zmínka o GIL (ačkoli tam není zmíněn explicitně svým názvem) je hned ve třetím odstavci. -- JŠ

Hodne lidi si stezuje na GIL. Ale vlakna v mnoha pripadech zjednodusuji programovani a nemusi byt je kvuli zvysovani vykonu. Proste vytvoreni threadu na nejakou ulohu je mnohdy jednodussi nez delat nejake timery apod. V GUI aplikacich je to jeste vice markantni.

Jinak je asi lepsi pouzivat try finally na odemykani zamku. Kdyz nastane vyjimka v try, tak nemate deadlock. Mozna jeste hezci je reseni pomoci nejakeho synchronized dekoratoru, ktery zamyka celou funkci. Proste neco jako scoped lock. Pak uz se chyba jen tezko dela.

Takhle to není moc ideální. Správné použití je:

lock = Lock()
...
with lock:
....

Problém je v tom, že with Lock(): vytvoří zámek a hned si ho vezme (navíc zámek není přiřazený do žádné proměnné, takže se nedá použít v jiném vlákně). Standardní postup je připravit si někde zámek a pak ho opakovaně používat v jednotlivých vláknech (viz uvedený příklad).

Fungování je jednoduché: třída implementuje metody __enter__() a __exit__(), při vyhodnocování výrazu v konstrukci with se zavolá __enter__(), při ukončení těla bloku (i v případě vyvolání výjimky, stejně jako u finally:) se zavolá __exit__(). Takže Lock v __enter__() zavolá self.acquire(), v __exit__() je self.release() a je vymalováno.

Možná je to jen můj názor, ale řekl bych, že by autorovi slušela trochu skromnost a pokora. Pokud si hraju s novou technologii víkend a tudíž jednak neznám ani pozadí impementace a její úskalí, ani nemám teoretický základ a rozhodnu se na takové téma napsat článek, tak bych na to hned v úvodu čtenáře upozornil a předem zkušenější pardy varoval, příp. je požádal o doplnění či opravu v diskusní části.

Možná je to jen můj názor, ale řekl bych, že by diskutérům slušela trochu skromnost a pokora a vděk, že pro ně někdo něco vůbec píše.

V tom případě se to netýká mne. Tenhle článek není pro mne. Za články Pavla Tišnovského vděčný jsem. Kdybyste četl diskuse pod jeho články, věděl byste to.

> V tom případě se to netýká mne. Tenhle článek není pro mne.

V tom případě by mě zajímalo, co vás vedlo k tomu napadat autora v diskuzi, když článek nebyl určen pro Vás. Měl jsem za to, že normální chování je v tu chvíli jít prostě pryč.

Proč myslíte, že jsem napadal autora? Napsal jsem mu konkrétní kontruktivní věcný kritický názor, který mu má pomoci zlepšit jeho články. Věnoval jsem autorovi svůj čas i přes to, že jsem ho mohl jako řada jiných ignorovat.

Protoze to, ze je to slatanina se clovek dozvi az po te, co si ten clanek precte. A proc by to pak jako nemel nepsat pod clanek, ze se mu takove hovadiny nelibi? Co az budu cist necemu cemu moc nerozumi a nepoznam ze je to slatanina? Pokud by ti, co tomu rozumi o tom nenapsali, budu za debila. Tekze jit pryc normalni chovani neni a ja jsem rad, kdyz se veci uvedou na pravou miru. A autor by si z toho mel vzit ponauceni a vyhnout se takovym hura akcim.

je hracka pro haranty, nic vic, nic min.

A co pouzivaji profici?

assembler ;)

What should all developers even rubyist know about threads: http://rubyconf2008.confreaks.com/what-all-rubyist-should-know-about-threads.html. Vlákna jsou obtížný a hlavně zastaralý koncept pro vývojáře. Programovat vlákna je strašně těžké a nikdo kromě vývojářů jádra, programovacích jazyků, virtuálních strojů a dalších úzce specializovaných věcí by neměl být nucen je programovat protože v tom naseká mraky chyb. Tak jako od dob Javy a dalších vyšších jazyků nejsou programátoři nuceni řešit GC, meze polí a další, tak by na začátku 21. století neměl být nucen řešit problémy s vlákny, zámky a semafory na takto nízké úrovni. Je načase se ohlédnout po lepší abstrakci třeba v jazycích jako Erlang, Clojure, F#, (J)OCaml, Oz (Mozart) nebo něčem podobném. Osobně doporučuji ten první.

Take si myslim, ze jsou problemy, ktere jsou paralelizovatelne velmi snadno a nopak jsou problemy, kde paralelizace je budto nemozna, nebo tak obtizna, ze za to nestoji. Klasickym pripadem prvniho typu je raytracing - po te, co se scena predzpracuje, se muze teoreticky kazdy pixel renderovat zvlast. Naopak numericke vypocty pomoci iteraci, pri kterych je pro vypocet nasledujiciho kroku nezbytne nutna hodnota z kroku predchoziho, se paralelizovat temer neda.

To už bych možná zmínil i Ousterhouta. ;-)

Bať a to se psal rok 1995. Jen bych nesouhlasil s Concurrency is fundamentally hard; avoid whenever possible. S Erlangem je concurrency celkem hračka i když i tam člověk může udělat chybu, ale je to řádově jednodušší než s vlákny. Jenže v té době byl ještě držen pod pokličkou v Ericssonu i když už měl za sebou deset let vývoje.

Dobra vec by se byla podivat na modul http://www.parallelpython.com/ .. umi prinutit python vyuzivat vlakna, jadra cpu i sitove nody celkem jednoduchou cestou