czy threading.Thread to zło i jak to jest z tymi wątkami w końcu

W skrócie: znam model threadingu w Pythonie, wiem o GILu, wiem że jest multiprocessing, wiem, że jest asyncio jak chcę nieblokująco itd. Używam tego kiedy trzeba (a generalnie wątków unikam także w C i C++ jak diabeł święconej wody bo "wątki trzeba umić" ;))

Niemniej, widzę że jednak z uporem maniaka co trochę ktoś ten threading.Thread wali do kodu. No i moje pytanie: czy a. jest aż tyle złego kodu i ludzie nie wiedzą w czym piszą (możliwe) b. może jednak jeśli ma to dawać jedynie prostotę myślenia w stylu "drugi task leci w tle" (vide taski na jednocore'wym procesorze na RTOSie: wiadomo że będą się zmieniać cyklicznie, ale jednak się ich używa w a'la wątkowy sposób) to nie jest to aż taka tragedia? Dla janości, mówię jednie o modelu myślowym, performance zostawiam na boku póki co.

EDIT: pytanie nie jest o wątki sensu stricte, bardziej o moduł threading który w zasadzie nie wydaje się mieć lepszego zastosowania niż logiczne porządkowanie tasków (nie liczę tu ręcznego przerzucania GILa), imho jest wręcz szkodliwy bo daje złudne poczucie równoległości.

Wątki używa się wtedy kiedy są potrzebne. Wszystko zależy od kontekstu

jeśli masz procesor jednowątkowy (i jesteś tego pewien na 100%) to wątki (taski, i wszystko co wymaga przełączenia kontekstu) jedyne co Ci da to spowolnienie wykonania. Jeśli natomiast masz "normalny" procek z 4, 6, 8, 12 czy 16 wątkami (stary i7 ma 12 wątków np.) to używanie wątków jest jak najbardziej pożądane.

Taka przypowieść
Obecnie pracuję w firmie, która rozwija swój produkt od ponad 35 lat (pierwsze wersje były dosowe). Z racji tego, że jest to pisane w różnych technologiach cała komunikacja między modułami opiera się o obiekty COM. Ktoś kiedyś wymyślił żeby nie utrudniać sobie życia to będziemy działać w trybie STA, czyli (bardzo z grubsza) obiekt COM musi być użyty w tym wątku, w którym został stworzony. To pociągnęło za sobą kolejne "wymyślenie" - to róbmy wszystko w głównym wątku. Dopóki procesory miały jeden rdzeń to nie było problemów ale aktualnie to wygląda tak, że program coś robi 5-10-15 minut, UI jest zwieszone, procesor działa na 10% (jeden wątek na full) a user czeka. Wreszcie ktoś "na górze" doszedł do wniosku, że można by coś z tym zrobić, tylko że nie jest tak łatwo zrównoleglić operacji, które nie były pisane z myślą o ich zrównoleglaniu. Także jeśli wiesz, że można coś policzyć równolegle to rób to od razu bo potem będzie kupa. I nie jest ważne czy opakujesz to w goły Thread czy weźmiesz do tego jakąś fancy bibliotekę - jednego i drugiego trzeba się nauczyć a rozumienie jak działa "goły" Thread wyjdzie Ci na plus (wszystkie Taski, Pararelle itd i tak wewnętrznie oparte są o Thread)

Jeśli już robię w Pythonie coś wielowątkowego, to zawsze używam multiprocessing. Jak już napisał @abrakadaber -- Thread spowolni robotę, bo wątek jest tylko wirtualny czyli daje współbieżność, ale ze względu na GILa nie równoległość). Można ewentualnie pomyśleć, że jakoś pozwala porządkować pracę, ale ja tego nie widzę -- bo po co, jeśli można od razu taki sam "porządek" zrobić przez multiprocessing...

jeśli masz procesor jednowątkowy (i jesteś tego pewien na 100%) to wątki (taski, i wszystko co wymaga przełączenia kontekstu) jedyne co Ci da to spowolnienie wykonania. Jeśli natomiast masz "normalny" procek z 4, 6, 8, 12 czy 16 wątkami (stary i7 ma 12 wątków np.) to używanie wątków jest jak najbardziej pożądane.

Tak, zgoda. Pisząc "unikam wątków" miałem raczej na myśli "unikam gołego api tam gdzie mogę bo często są lepsze abstrakcje". To nie o to chodzi, że pytam stricte o wątki (aczkolwiek uważam, że często bywają one nadużywane tam gdzie można było przemysleć design... no ale to jakby osobny temat kompletnie).

Jeśli już robię w Pythonie coś wielowątkowego, to zawsze używam multiprocessing.

No ja też.

Można ewentualnie pomyśleć, że jakoś pozwala porządkować pracę, ale ja tego nie widzę -- bo po co, jeśli można od razu taki sam "porządek" zrobić przez multiprocessing...

threading ma chyba (zwłaszcza w staryszch pythonach) lepsze abstrakcje. Inaczej: zastanawiam się - trochę może filozoficznie - po jaki kij ten moduł w pythonie w ogóle jest (ręcznego zarządzania GILem tu nie wliczam) skoro nie ma innego zadania niż porządkowanie tasków.

A, jeszcze jedno z dokumentacji https://docs.python.org/3/library/threading.html
However, threading is still an appropriate model if you want to run multiple I/O-bound tasks simultaneously.
-- to ewentualnie może mieć sens, bo multiprocessing może dawać dodatkowy narzut... (pamięciowy/zasobowy, bo czasowy przy IO jest raczej do pominięcia).

alagner napisał(a):

threading ma chyba (zwłaszcza w staryszch pythonach) lepsze abstrakcje. Inaczej: zastanawiam się - trochę może filozoficznie - po jaki kij ten moduł w pythonie w ogóle jest (ręcznego zarządzania GILem tu nie wliczam) skoro nie ma innego zadania niż porządkowanie tasków.

Starszych Pythonów (które masz na myśli?) należy przestać używać :) a abstrakcja obu modułów jest taka sama w aktualnych wersjach. O to się starali autorzy od samego początku.

Ale co ciekawe:

Changed in version 3.7: This module used to be optional, it is now always available.

Także to też daje do myślenia.

Błędnie zaimplementowane wątki oraz operacje zmiennoprzecinkowe doprowadziły do wielu poważnych wypadków.
http://www-users.math.umn.edu/~arnold/disasters/patriot.html
Jeżeli ktoś nie wiedział, że inkrementacja zmiennej to trzy operacje atomowe na CPU to mógł sporo nabroić.
https://ucgosu.pl/2018/09/therac-25-czyli-blad-w-sofcie-medycznym-powodujacy-smierc-pacjentow/

Pytanie do autora:
Czy łatwiej zrobić implementację modułu threading czy zrobić "klej" do języka C/C++?

@Marcin Marcin: Nie wiem czy to jest pytanie na ten wątek (no pun intended ;) ), ale imho łatwiej będzie dokleić C++, przy czym ja głównie programuję w C++, a Python to dla mnie język pomocniczy, także moja perspektywa może determinować moją opinię. BTW, do wpinania C++ masz bardzo fajnie sprawdzający się moduł boost.python, przy czym ztcw to Cię i tak z zarządzania gilem nie zwalnia. Może to Ci pomoże https://pieceofpy.com/2010/02/26/boost-python-threads-and-releasing-the-gil/