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