Чому б не зелені нитки?

Хоча я знаю, що питання з цього питання вже висвітлювалися (наприклад, https://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads ), я не відчуваю, що я отримав задовільну відповідь .

Питання: чому JVM більше не підтримує зелені нитки?

Це говорить про FAQ у стилі Java :

Зелена нитка посилається на режим роботи для віртуальної машини Java (JVM), в якому весь код виконується в одному потоці операційної системи.

І це все на java.sun.com :

Мінусом є те, що використання зелених ниток означає, що системні потоки в Linux не використовуються, і тому віртуальну машину Java не можна масштабувати, коли додаються додаткові процесори.

Мені здається, що JVM може мати пул системних процесів, рівний кількості ядер, а потім виконувати зелені нитки поверх цього. Це може запропонувати великі переваги, коли у вас дуже велика кількість потоків, які часто блокуються (в основному через те, що поточне обмеження JVM має кількість потоків).

Думки?

Я пам’ятаю, що JVM відмовився від зелених ниток і перейшов до рідних ниток. Це було з двох простих причин: зелені нитки були відверто сміттями, і виникла потреба у підтримці багатоядерних процесорів з обмеженими зусиллями розробника, наявними в Sun.

Це було прикро - зелені нитки забезпечують набагато кращу абстракцію, дозволяючи одночасності бути корисним інструментом, а не каменем спотикання. Але зелені нитки не корисні, якщо кілька перешкод неможливо подолати:

• вони повинні використовувати всі наявні у них процесорні ядра

• контекстна комутація повинна бути дешевою

• I / O може блокувати будь-який потік, що займається ним, але не будь-який інший потік і, звичайно, не всі інші потоки, що було в деяких ранніх впровадженнях.

Я часто замислювався, чому багатоструменевий настільки важкий на Java, але тепер він стає зрозумілішим - це, зрештою, було пов'язано з переходом на рідні теми, які є:

• добре використовувати всі ядра процесора

• добре бути справді одночасним, забезпечуючи незалежне введення / виведення тощо

• повільне переключення контексту (порівняно з найкращими реалізаціями зеленої нитки)

• жахливо жадібні пам’яті, отже, обмежуючи їх максимально корисну кількість

• погана абстракція будь-якої основи для вираження реального світу, що, безумовно, суперечить.

В даний час багато програмного часу йде на кодування неблокуючих вводу-виводу, ф'ючерсів тощо. Велика ганьба, що у нас немає кращого рівня абстракції.

Для порівняння, окрім Ерланга, нова мова Go робить непогану роботу з величезною одночасністю. Бабуся-тато з них все ще залишається Occam , як і раніше триває дослідницький проект.

Один процес підроблення декількох потоків має безліч проблем. Один з них полягає в тому, що всі підроблені нитки застоюються на будь-якій сторінці помилки.

Альтернатива, яку ви пропонуєте, пул процесів, має деякі переваги та деякі недоліки. Найбільша перевага, ізоляція «ниток», насправді не принесла б вам тут багато чого. Великий недолік, надзвичайна складність впровадження та менш ефективна синхронізація - тут є вбивцею.

Однак я погоджуюся з тим, що існують деякі програми (не Java), де пул процесів, який ви могли б використовувати як пул потоків (але з більшою ізоляцією), була б чудовою справою. Нитки діляться майже всім. За допомогою процесів ви можете конкретно вибрати, чим поділитися. Наскільки мені відомо, ще ніхто не доклав зусиль щодо її реалізації.

Користь для середнього коду Java взагалі не буде корисною. Java - це не Ерланг, і Java-програмісти не мають такого ж мислення, як програмісти Erlang. Мова ніколи не передбачалася використовувати таким чином.

Якщо ви хочете справжньої легкої обробки даних - використовуйте Erlang і створіть тисячі потоків, що спілкуються через повідомлення. У Java у вас буде десяток потоків, які спільної пам’яті мають мутекси та семафори. Це просто інша модель програмування, розроблена для різного набору проблем.