Dlaczego nie zielone wątki?

Chociaż wiem, że pytania na ten temat zostały już omówione (np. Https://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads ), nie wydaje mi się, żebym uzyskał zadowalającą odpowiedź .

Pytanie brzmi: dlaczego JVM nie obsługuje już zielonych wątków?

Mówi to na często zadawanych pytaniach w stylu Java :

Zielony wątek odnosi się do trybu działania wirtualnej maszyny Java (JVM), w którym cały kod jest wykonywany w jednym wątku systemu operacyjnego.

I to na java.sun.com :

Minusem jest to, że użycie zielonych wątków oznacza, że ​​wątki systemowe w systemie Linux nie są wykorzystywane, a zatem wirtualna maszyna Java nie jest skalowalna po dodaniu dodatkowych procesorów.

Wydaje mi się, że JVM może mieć pulę procesów systemowych równą liczbie rdzeni, a następnie uruchamiać na nim zielone wątki. Może to oferować duże korzyści, gdy masz bardzo dużą liczbę wątków, które często blokują (głównie dlatego, że bieżąca JVM ogranicza liczbę wątków).

Myśli?

Pamiętam, jak JVM porzuciła zielone wątki i przeniosła się do wątków rodzimych. Stało się tak z dwóch prostych powodów: zielone wątki były szczerze mówiąc śmieciami, a także trzeba było wspierać procesory wielordzeniowe przy ograniczonym nakładzie pracy programistów dostępnym w firmie Sun.

Szkoda - zielone wątki zapewniają znacznie lepszą abstrakcję, pozwalając, aby współbieżność była użytecznym narzędziem, a nie przeszkodą. Ale zielone nici nie przydadzą się, jeśli nie uda się pokonać kilku przeszkód:

• muszą używać wszystkich dostępnych rdzeni procesorów

• przełączanie kontekstu musi być tanie

• I / O może blokować każdy wątek w nim zaangażowany, ale nie żaden inny wątek, a na pewno nie wszystkie inne wątki, co miało miejsce w niektórych wczesnych implementacjach.

Często zastanawiałem się, dlaczego wielowątkowość jest tak trudna w Javie, ale teraz staje się jaśniejsza - ostatecznie miało to związek z przejściem na wątki rodzime, które są:

• dobry w użyciu wszystkich rdzeni procesora

• dobry w byciu naprawdę współbieżnym, zapewniając niezależne wejścia / wyjścia itp

• powolne przełączanie kontekstu (w porównaniu z najlepszymi implementacjami zielonego wątku)

• okropnie chciwy pamięci, ograniczając w ten sposób maksymalną ich użyteczną liczbę

• słaba abstrakcja jakiejkolwiek podstawy wyrażania świata rzeczywistego, co oczywiście jest wysoce zbieżne.

W dzisiejszych czasach dużo czasu programisty zajmuje kodowanie nieblokujących wejść / wyjść, kontraktów terminowych itp. Szkoda, że ​​nie mamy lepszego poziomu abstrakcji.

Dla porównania, oprócz Erlanga, nowy język Go ma dobrą robotę z ogromną współbieżnością. Dziadek ze wszystkich pozostaje Occam , wciąż trwającym projektem badawczym.

Pojedynczy proces fałszowania wielu wątków ma wiele problemów. Jednym z nich jest to, że wszystkie sfałszowane wątki zatrzymują się na każdej stronie.

Sugerowana przez ciebie alternatywa, pula procesów, ma pewne zalety i wady. Największą zaletą, izolacją „wątków”, tak naprawdę niewiele by cię tu sprowadzało. Wielka wada, ekstremalna trudność implementacji i mniej wydajna synchronizacja są tutaj zabójcą transakcji.

Zgadzam się jednak, że istnieją pewne aplikacje (nie Java), w których pula procesów, których można by użyć, jak pula wątków (ale z większą izolacją) byłaby świetna. Wątki dzielą się prawie wszystkim. Dzięki procesom możesz konkretnie wybrać, co chcesz udostępnić. Według mojej wiedzy nikt jeszcze nie podjął wysiłku, aby go wdrożyć.

Przeciętny kod Java nie przyniesie żadnych korzyści. Java to nie Erlang, a programiści Java nie są tak samo nastawieni jak programiści Erlang. Tego języka nigdy nie zamierzano używać w ten sposób.

Jeśli chcesz prawdziwie lekkich procesów - skorzystaj z Erlanga i stwórz tysiące wątków komunikujących się za pośrednictwem wiadomości. W Javie masz tuzin wątków współużytkujących wspólną pamięć z muteksami i semaforami. To po prostu inny model programowania, zaprojektowany dla innego zestawu problemów.