Názory k článku Python: skriptování ve více vláknech
-
...no a abych jen nerejpal, posilam link na modul, ktery GIL obejde (pozor, novinka v pythonu 2.6).
http://docs.python.org/library/multiprocessing.html#module-multiprocessing -
Inkvizitor (neregistrovaný)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.
-
Po proletnuti clanku se mi zda, ze Vam unikla dost zasadni informace, a to sice existence Global Interpreter Locku. Jde o zamek, ktery ma kazdy proces s pythonim interpretrem, a ktery prakticky znemoznuje paralelni spousteni vlaken, proto jsou vlakna v Pythonu spise zbytecny overhead navic. Ac jsem velky nadsenec do Pythonu, tak musim rict (a nejen ja), ze thready jsou v Pythonu docela zlo. Mozna ten Stackless Python je na tom lepe... Dalsi informace http://en.wikipedia.org/wiki/Global_Interpreter_Lock .
Pokud chcete opravdu zpracovavat neco paralelne, musite si pustit vice procesu a tim padem vice interpretru, kde ma kazdy svuj globalni zamek. Neni to zas tak slozite, otazka je, jestli to nezere moc prostredku a neni to nekdy moc kanon na vrabce, preci jenom vlakna jsou vlakna...
Dalsi moznosti je Python 3.x, ktery obsahuje modul multiprocessing tusim, ktery vypada zvenci jako thready, ale uvnitr se pousteji procesy.
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. Je to podobne jako odblokovat a pak zase zablokovat mutex. -
Článek vycházel hlavně z http://docs.python.org/library/threading.html#module-threading . Tam o tom není ani zmínka :( Teď koukám na http://docs.python.org/library/multiprocessing.html#module-multiprocessing a tam se o tom píše, takže bych měl ještě jeden článek věnovat tomuto modulu. -
linuxnew (neregistrovaný)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...
-
Inkvizitor (neregistrovaný)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í.
-
Wrunx (neregistrovaný)
No, já jsem víceméně laik, takže jen postřeh: Když si pustím šest threadů python 2.7.8 na osmijádru AMD FX-8350, tak vidím na grafu procesorů že jich to opravdu 6 vytěžuje... ale ne na 100 %, ale tak na 40. Čili imho na více jádrech to rozhodně běží, ale jak efektivně, toť otázka, protože když si spustím v několika konzolích po jednom skriptu, tak všechny běží prakticky na 100... :-)
-
anonymníO GIL se pise treba tady: http://heather.cs.ucdavis.edu/~matloff/Python/PyThreads.pdf
Pokud se autor podival jen do http://docs.python.org, tak tam skutecne neni v kapitolach o threadingu ani carka. -
zde (neregistrovaný)> 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í. -
Ano mate pravdu, nic tak extremniho na tom neni, jenom jsem to psal v 1 hodinu rano a tak nejak se mi asi zdalo, ze v kontextu programovani v Pythonu to nekomu muze prijit slozitejsi, takze to melo znit mozna trosku jako varovani ve smyslu "pozor, neni to takova sranda, jako proste psat v Pythonu", ale jinak opakuji, souhlasim s Vami.
-
Inkvizitor (neregistrovaný)> 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é. -
Karell (neregistrovaný)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 ;-) -
anonymníPane Štrauchu, nedá mi to, ale téměř před sedmi lety jsem totéž (včetně zmínky o GIL) popsal zde: http://www.root.cz/clanky/letajici-cirkus-13/
-
Hmm, ačkoliv je Váš článek ohledně vláken o kus lepší než od pana Štraucha, problematiku GIL jsem tam neobjevil, možná je v jiných dílech Létajícího cirkusu. Proto jsem rád, že se téma znovu otevřelo.
Osobně jsem rád, že se objevují články z různých pokusů pana Štraucha, obvykle je diskuze pod článkem velmi plodná, až tedy na některé rádoby kritiky, kteří se asi nikdy nenaučí konstruktivně diskutovat, čímž nemyslím Vás.
Mnoho potencionálních autorů, zde přispívá a doplňují, co článku chybí, ačkoliv jinak nevidím žádné jejich články, mnohdy evidentně na škodu věci.
Držím palce všem, kteří se nebojí sdílet své názory, nápady, studium a hledání, byť přitom mnohdy šlápnou vedle nebo se na jejich hlavu sype vagón opovržení od ostatních lidí. -
tom (neregistrovaný)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. -
Ano, try - finally se hodi. Dokonce na to autori Pythonu mysleli tak, ze existuje takova pekna konstrukce, neco jako
from threading import LockNekde jsem to videl a melo by to samo odemykat zamek, ale nevim, jak to nakonec funguje, kdo chce vedet vic, ma tady PEP. Pokud pisu neco nepresne, tak se omlouvam, nemam to nastudovane...
with Lock():
(...)
-
Inkvizitor (neregistrovaný)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). -
Inkvizitor (neregistrovaný)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.
-
ToM (neregistrovaný)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.
-
Michal SmržStříbrný podporovatelMož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. -
Michal SmržStříbrný podporovatel> 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č. -
Petr (neregistrovaný)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.
-
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í.
-
Kvakor (neregistrovaný)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.
-
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.
-
mimi.vx (neregistrovaný)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
ČLÁNKY DO MAILU