Рубин имеет реальную многопоточность?

(К сожалению, только две из тех 11 реализаций на самом деле готовы к производственному использованию, но к концу года, к которому число, вероятно, подойдет четыре или пять.) ( Обновление : это теперь 5: МРТ, JRuby, YARV (интерпретатор для Ruby 1.9), Rubinius и IronRuby).

1. первая реализация на самом деле не имеет имени, которое делает довольно неудобным относиться к ней и является действительно раздражающим и сбивает с толку. Это чаще всего упоминается как "Ruby", который является еще более раздражающим и сбивает с толку, чем наличие никакого имени, потому что это приводит к бесконечному беспорядку между функциями Языка программирования Ruby и конкретной Реализации Ruby.

   Это также иногда называют "МРТ" (для Реализации Ruby "Matz"), CRuby или MatzRuby.

   МРТ реализует Потоки Ruby как Зеленые Потоки в его интерпретаторе . К сожалению, это не позволяет тем потокам быть запланированными параллельно, они могут только выполнить один поток за один раз.

   Однако любое количество Потоков C (Потоки POSIX и т.д.) может работать параллельно к Потоку Ruby, так внешние Библиотеки C или МРТ C Расширения, которые создают собственные потоки, может все еще работать параллельно.

2. вторая реализация YARV (коротка для "еще одного Ruby VM"). YARV реализует Потоки Ruby как POSIX или Потоки Windows NT , однако, это использует Глобальную блокировку интерпретатора (GIL), чтобы гарантировать, что только один Поток Ruby может на самом деле быть запланирован в любой момент.

   Как МРТ, C Потоки может на самом деле идти параллельно Потокам Ruby.

   В будущем, это возможно, что GIL мог бы разламываться на более мелкомодульные блокировки, таким образом позволяя все большему количеству кода на самом деле работать параллельно, но это до сих пор находится далеко, это даже не , запланировал все же.

3. JRuby реализует Потоки Ruby как Собственные Потоки , где "Собственные Потоки" в случае JVM, очевидно, означает "Потоки JVM". JRuby не налагает дополнительной блокировки на них. Так, могут ли те потоки на самом деле работать, параллельно зависит от JVM: некоторые JVMs реализуют Потоки JVM как Потоки ОС и некоторых как Зеленые Потоки. (Основные JVMs от Sun/Oracle используют исключительно потоки ОС начиная с JDK 1.3)

4. XRuby также реализации Потоки Ruby как Потоки JVM . Обновление : XRuby мертв.

5. IronRuby реализует Потоки Ruby как Собственные Потоки , где "Собственные Потоки" в случае CLR, очевидно, означает "Потоки CLR". IronRuby не налагает дополнительной блокировки на них, таким образом, они должны работать параллельно, пока Ваши поддержки CLR это.

6. Ruby.NET также реализации Потоки Ruby как Потоки CLR . Обновление: Ruby.NET мертв.

7. Rubinius реализует Потоки Ruby как Зеленые Потоки в его Виртуальной машине . Более точно: Rubinius VM экспортирует очень легкую, очень гибкую concurrency/parallelism/non-local конструкцию потока управления, названную" Задача ", и все другие конструкции параллелизма (Потоки в этом обсуждении, но также и Продолжения , Агенты и другой материал) реализованы в чистом Ruby, с помощью Задач.

   Rubinius не может (в настоящее время) планировать Потоки параллельно, однако, добавляя, что это не слишком много проблемы: Rubinius уже может выполнять несколько экземпляров VM в нескольких Потоках POSIX в параллели , в рамках одного процесса Rubinius. Так как Потоки на самом деле реализованы в Ruby, них, как любой другой объект Ruby, могут быть сериализированы и отправлены в различный VM в различном Потоке POSIX. (Это - та же модель ЛУЧ использование Erlang VM для параллелизма SMP. Это уже реализовано для Агентов Rubinius .)

   Обновление : информацией о Rubinius в этом ответе является о Ружье VM, который больше не существует. "Новый" C++ VM не использует зеленые потоки, запланированные через несколько VMs (т.е. стиль Erlang/BEAM), это использует более традиционный единственный VM с несколькими собственной моделью потоков ОС, точно так же, как та, используемая, скажем, CLR, Моно, и в значительной степени каждая JVM.

8. MacRuby, начатый как порт YARV сверху Платформ CoreFoundation и Времени выполнения и Какао Objective C. Это теперь значительно отличалось от YARV, но AFAIK это в настоящее время тихий доли та же Модель потоков с YARV. Обновление: MacRuby зависит от сборщика "мусора" яблок, который объявляется удержанный от использования и будет удален в более поздних версиях MacOSX, MacRuby немертв.

9. Кардиналом является Реализация Ruby для Виртуальная машина Попугая . Это еще не реализует потоки, однако, когда это сделает, это, вероятно, реализует их как [1 125] Потоки Попугая . Обновление : Кардинал кажется очень неактивным/мертвым.

10. MagLev является Реализация Ruby для GemStone/S Smalltalk VM. У меня нет информации, какая модель потоков использование GemStone/S, что модель потоков использование MagLev или даже если потоки даже реализованы уже (вероятно, не).

11. HotRuby не полная собственная Реализация Ruby. Это - реализация байт-кода YARV VM в JavaScript. HotRuby не поддерживает потоки (уже?) и когда это делает, они не будут в состоянии работать параллельно, потому что JavaScript не имеет никакой поддержки истинного параллелизма. Существует версия ActionScript HotRuby, однако, и ActionScript мог бы на самом деле поддерживать параллелизм. Обновление : HotRuby мертв.

, К сожалению, только две из этих 11 Реализаций Ruby на самом деле готовы к производству: МРТ и JRuby.

Так, если Вы хотите истинные параллельные потоки, JRuby в настоящее время является Вашим единственным choice †“не, что это - плохое: JRuby на самом деле быстрее, чем МРТ и возможно более стабилен.

Иначе, "классическое" решение Ruby состоит в том, чтобы использовать процессы вместо потоков для параллелизма. Оперативная библиотека Ruby содержит Process модуль с Process.fork метод , который делает очень легким разветвиться от другого процесса Ruby. Кроме того, Библиотека Стандарта Ruby содержит Распределенный Ruby (dRuby / dRb) библиотека, которая позволяет коду Ruby быть тривиально распределенным через несколько процессов, не только на той же машине, но также и по сети.