Воссоздание потоков и знаний параллелизма на все более популярных языках

Question

Я в первую очередь Java-разработчик, и я много читал о работе с потоками и параллелизмом. Многие очень умные люди (Дуг Ли, Брайан Гетц и т. Д.) Создали книги на эти темы и внесли свой вклад в новые библиотеки параллелизма для Java.

Когда я начинаю больше изучать Python, Ruby и другие языки, я задаюсь вопросом: нужно ли заново создавать всю эту работу для этих языков?

Будет ли или должен быть «Даг Леа из Python» или «Брайан Гетц из Ruby», которые вносят столь же значительный вклад в возможности параллелизма этих языков?

Нужно ли заново создавать всю эту работу по параллелизму, выполненную на Java, для будущих языков? Или работа, выполненная на Java, послужит уроками и руководством для будущих языков?

Answer 1

Основные принципы параллельного программирования существовали до Java и были обобщены в тех книгах Java, о которых вы говорите. Библиотека java.util.concurrent была аналогично получена из предыдущего кода и исследовательских работ по параллельному программированию.

Однако некоторые проблемы реализации специфичны для Java. У него есть определенная модель памяти, и параллельные утилиты в Java адаптированы к специфике этого. С некоторыми изменениями они могут быть перенесены на другие языки / среды с другими характеристиками модели памяти.

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

Answer 2

Имейте в виду, что потоки являются лишь одной из нескольких возможных моделей для работы с "параллелизмом". Например, в Python есть одна из самых продвинутых асинхронных (основанных на событиях) не поточных моделей в Twisted . Неблокирующие модели довольно мощные и используются в качестве альтернативы потокам в большинстве приложений с самым высоким масштабированием (например, nginx, lighttpd).

Ваше предположение о том, что другим популярным языкам нужны потоки, может просто являться признаком Java-ориентированного (и, следовательно, ориентированного на потоки) мировоззрения. Взгляните на страницу C10K , чтобы немного устаревшим, но высокоинформативным взглянуть на несколько моделей для обработки больших объемов параллельных запросов.

Answer 3

Я думаю, что ответ и да, и нет. Java, возможно, имеет наиболее четко определенную модель памяти и семантику выполнения из наиболее часто используемых императивных языков (Java, C ++, Python, Ruby и т. Д.). В некотором смысле, другие языки либо полностью этого не испытывают, либо играют в догонялки (если это даже возможно, учитывая незрелость потоковых моделей).

C ++, вероятно, является заметным исключением - он занимал ту же почву для C ++ 0x и, возможно, вышел за рамки текущего состояния модели Java из моего впечатления.

Я говорю нет, потому что сообщества не изолированы. Многие ребята, работающие над этим материалом, вовлечены (по крайней мере, с точки зрения руководства, если не с прямой стороны в спецификации) в более чем один язык. Таким образом, между ребятами, работающими над JMM, и ребятами, работающими над спецификациями C ++ 0x, существует множество перекрестных связей, поскольку они по существу решают одни и те же проблемы со многими из тех же базовых драйверов (от аппаратных парней внизу и пользователей из Топ). И я почти уверен, что на каком-то уровне между лагерями JVM / CLR есть перекрестные разговоры.

Как уже упоминалось, есть и другие модели параллелизма: актеры в Erlang и Scala, агенты / STM в Clojure, рост FP в F #, Scala, Haskell, CCR и PLINQ в CLR и т. Д. Это захватывающее время прямо сейчас! Мы можем использовать столько экспертов по параллелизму, сколько сможем найти, я думаю ....:)

Answer 4

Kamaelia - это проект (который я начал и продолжаю работать), целью которого является создание параллелизма как инструмента, который вы хотите использовать, а не как боль в использовании. С практической точки зрения это означает, что это в первую очередь модель без совместного использования ресурсов с моделью передачи сообщений (основанная на взгляде на мир из каналов Occam & Unix).

В основе этой цели лежит стремление сделать параллелизм простым в использовании для среднего разработчика, защищая его от более неприятных проблем, вызванных рядом подходов к параллелизму. (На слайде есть куча презентаций, объясняющих, почему и как там)

Кроме того, он предоставляет простую программную модель транзакционной памяти для ситуаций, когда необходимо обмениваться данными, и использует преднамеренно простой API.

Основная реализация Kamaelia на python, с игрушечной реализацией на Ruby & C ++. Кто-то перенес базовый подход на E, а также на Java. (хотя Java-человек исчез) (Реализация игрушек - это проверка работоспособности, идеи могут работать на других языках, если их необходимо преобразовать в локальные идиомы)

Возможно, ваш вопрос должен состоять не в том, «чему могут научиться эти языки», а в том, «чему может научиться сообщество Java, глядя в другое место?». Многие люди, которые изучают Python, являются лингвистически иммигрантами из других стран и приносят с собой свои знания других языков, и поэтому с того места, где я сижу, похоже, что Python уже ищет вдохновения для других языков.

Выбор чего-то конкретного, например, это приложение для разговора и записи - инструмент для обучения маленькому ребенку чтению и письму, основанный на перьевом вводе, распознавании рукописного ввода и синтезаторе речи - использует несколько дюжина параллельных подсистем, работающих на приемлемой скорости на одноядерном компьютере, легко может быть запущена на многоядерном компьютере. Однако причина количества одновременных подсистем не связана с «желанием сделать приложение параллельным», а больше связана с «Как сделать приложение проще в написании, расширении и обслуживании?». Тот факт, что он оказывается смущающе параллельным, является вторичным бонусом.

Есть полный учебник - Прагматический параллелизм - связанный с первой страницы. (Примечания, слайды, видео и кодовый пакет)

Модель может быть улучшена, и предложения приветствуются - жизнь была бы очень скучной, если бы мы все просто «перестали» пытаться делать лучшие инструменты - но игнорирование того, что уже существует, кажется немного ... узким. Если это кажется немного резким, пожалуйста, посмотрите на сегодняшний Дильберт .

: -)

Answer 5

Это не приманка пламени, но IMHO Java имеет одну из более простых и более ограниченных моделей для многопоточности и параллелизма. Это не обязательно плохо, но на уровне детализации, который он предлагает, это означает, что перспектива, которую он дает вам относительно того, что такое параллелизм и как с ним бороться, по своей сути ограничена, если у вас есть представление, ориентированное на Java (как кто-то другой сказал это).

Если вы серьезно относитесь к параллелизму, тогда стоит изучить другие языки именно , потому что существуют различные модели и идиомы.

Некоторые из самых горячих областей - это программирование без блокировок (вы увидите его много, но часто это плохо делается в C ++) и функциональное программирование (которое существует уже некоторое время, но, вероятно, становится все более актуальным). Главный пример в случае параллелизма - это, вероятно, Erlang).