Vlákno názorů k článku Python: skriptování ve více vláknech od Inkvizitor - > Bohužel právě na vývojáře aplikací jsou tím...

> 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.