Какой практический эффект будет, различные модели потоков Ruby (Ruby по сравнению с JRuby) имеют на Вашем коде как разработчик?
CountDownLatch: Если мы хотим, чтобы все наши потоки выполняли
что-то + обратный отсчет
, чтобы другие ожидали ] (чтобы счетчик достиг нуля) нити могут продолжаться, мы можем использовать защелку обратного отсчета. Все предыдущие потоки, которые фактически выполняли обратный отсчет, могут в этом случае продолжить работу, но нет никакой гарантии, что строка , обработанная после latch.countdown (), будет после ожидания, когда другие потоки достигнут latch.countdown () , но он имеет гарантию, что другие ожидающие потоки будут запускаться дальше только после того, как latch.await () достигнет нуля.
CyclicBarrier: Если мы хотим, чтобы все наши потоки
делали что-то + ожидали в общей точке + делали что-то
( каждый вызов await будет уменьшать время ожидания продолжения потоков)
Функциональность CyclicBarrier может быть достигнута CountDownLatch только один раз, вызвав latch.countdown (), за которым следует latch.await () всеми потоками.
но снова вы не можете сбросить / использовать обратный отсчет.
Лучший пример, где я использовал CyclicBarrier, - это инициализация нескольких кэшей (нагретых несколькими потоками), а затем начало дальнейшей обработки, и я хотел снова инициализировать другие кэши в Sync.
3 ответа
Потоки JRuby являются собственными системными потоками, поэтому они дают вам все преимущества многопоточного программирования (включая использование нескольких ядер процессора, если применимо). Однако в Ruby есть глобальная блокировка интерпретатора (GIL), которая предотвращает одновременное выполнение нескольких потоков. Таким образом, единственная реальная разница в производительности заключается в том, что ваши приложения MRI / YARV Ruby не смогут использовать все ядра вашего процессора, но ваши приложения JRuby с радостью это сделают.
Однако, если это не проблема. , Потоки MRI (теоретически, я не тестировал это) немного быстрее, потому что они зеленые потоки , которые используют меньше системных ресурсов. YARV (Ruby 1.9) использует собственные системные потоки.
Я обычный пользователь JRuby, и самое большое отличие состоит в том, что потоки JRuby действительно параллельны. На самом деле они являются потоками системного уровня, поэтому их можно выполнять одновременно на нескольких ядрах. Я не знаю места, где код MRI Ruby 1.8 работает медленнее на JRuby. Вы можете проверить этот вопрос Есть ли в Ruby настоящая многопоточность? .
Состояние
- Ruby 1.8 имеет зеленые потоки, они быстро создаются / удаляются (как объекты), но не выполняются параллельно и даже запланировано операционной системой, но виртуальной машиной
- ruby 1.9 имеет реальные потоки, они медленно создаются / удаляются (как объекты) из-за вызовов ОС, но из-за GIL (глобальной блокировки интерпретатора), которая позволяет выполнять только один поток за раз, ни то, ни другое не является по-настоящему параллельным
- JRuby также имеет реальные потоки, запланированные ОС, и они действительно параллельны
Заключение
Многопоточная программа, работающая на 2-ядерном ЦП, будет работать на JRuby быстрее, чем другие реализации, с точки зрения потоковой передачи
Уведомление!
Многие существующие библиотеки Ruby не являются потокобезопасными, поэтому преимущество JRuby во много раз бесполезно.
Также обратите внимание, что многие методы программирования на Ruby (например, vars классов) потребуют дополнительных усилий по программированию для обеспечения безопасности потоков (блокировки мьютексов, мониторы и т. Д.), Если нужно использовать потоки.