Какие высокоуровневые языки поддерживают многопоточность?

Erlang имеет встроенную поддержку параллельного программирования.

Строго говоря Erlang processe являются greenlets. Но язык и виртуальная машина разработаны с нуля для поддержки параллелизма. Язык имеет определенные управляющие структуры для асинхронного межпроцессного обмена сообщениями.

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

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

С CPython нужно помнить о GIL. Подводить итог: только один процессор используется, даже на многопроцессорных машинах. Существует несколько путей вокруг этого как шоу комментария.

Более старые версии C и C++ (а именно, C89, C99, C++ 98 и C++ 03) не имеют никакой поддержки вообще на базовом языке, хотя библиотеки, такие как потоки POSIX доступны для в значительной степени каждой платформы в обычном пользователе сегодня.

Новейшие версии C и C++, C11 и C++ 11, действительно имеют встроенную поддержку поточной обработки на языке, но это - дополнительная функция C11, таким образом, реализации, такие как одножильные встроенные системы могут принять решение не поддерживать его при поддержке остальной части C11, если они требуют.

Delphi/FreePascal также имеет поддержку потоков.

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

Некоторые хорошие библиотеки, которые реализуют лучшие опции сверху Объекта TThread:

• OmniThreadLibrary
• BMThread

Clojure и ближайший диалект Lisp для JVM, которая специально предназначена для обработки параллелизма хорошо.

Это показывает функциональный стиль API, некоторые очень эффективные внедрения различных неизменных структур данных и система агента (бит как агенты в Scala, и обрабатывает в Erlang). Это даже имеет программное обеспечение транзакционная память.

В целом, Clojure переходит к большой длине, чтобы помочь Вам написать корректный многопоточный и параллельный код.

Необходимо определить "собственный компонент" в этом контексте.

Java требует своего рода встроенной многопоточности, но основан просто на крупномодульной блокировке и некоторой поддержке библиотеки. В данный момент это не является более 'собственным', чем C с потоками POSIX. Следующая версия C++ (0x) будет включать библиотеку поточной обработки также.

Я полагаю, что официальный писк, VM не поддерживает собственный компонент (ОС) потоки, но что версия Драгоценного камня делает.

(Не стесняйтесь редактировать это если не корректный).

Я знаю Java и многопоточность поддержки C# и что следующая версия C++ будет поддерживать его непосредственно... (Запланированная реализация доступна как часть библиотек boost.org...),

Повышение:: поток является большим, я не уверен, можно ли сказать что его часть языка все же. Это зависит, если Вы полагаете, что CRT/STL/повышение 'часть' C++ или дополнительная дополнительная библиотека.

(иначе практически никакой язык не имеет собственный компонент, распараллеливающий, поскольку они - весь функция ОС).

Perl полезно не поддерживает собственные потоки.

Да, существует модуль потоков Perl, и да он использует собственные потоки платформы в своей реализации. Проблема, это не очень полезно в общем случае.

При создании нового потока с помощью потоков Perl он копирует все состояние интерпретатора Perl. Это очень медленно и использует много RAM. На самом деле это, вероятно, медленнее, чем использование ветвления () на Unix, поскольку последняя копия на записи использования и потоки Perl не делают.

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

Разве потоки не являются вышедшими из моды в эти дни в пользу процессов? (Думайте Google Chrome, IE8),

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

Существуют реализации Java, которые используют собственные потоки и реализации Java, которые используют зеленые потоки.
Существуют реализации Ruby, которые используют собственные потоки и реализации Ruby, которые используют зеленые потоки.
Существуют реализации Python, которые используют собственные потоки и реализации Python, которые используют зеленые потоки.
Существуют даже реализации Потока POSIX, которые используют зеленые потоки, например, старую библиотеку LinuxThreads или GNU pth библиотека.

И просто потому что собственные потоки использования реализации не означают, что эти потоки могут на самом деле работать параллельно; много реализаций используют Глобальную Блокировку Интерпретатора, чтобы гарантировать, что только один поток может работать за один раз. С другой стороны, использование зеленых потоков не означает, что они не могут работать параллельно: ЛУЧ Erlang VM, например, может запланировать свои зеленые потоки (более точно зеленые процессы) через mulitple ядра процессора, то же, планируется VM Rubinius Ruby.

Я сделал расширение многопоточности для Lua недавно, названным Маршрутами Lua. Это объединяет понятия многопоточности так естественно с языком, что я не видел бы 'созданный в' многопоточности, являющейся немного лучше.

Для записи Lua создал в совместной многопоточности (сопрограммы), может часто также использоваться. С или без Маршрутов.

Маршруты не имеют никакого GIL и выполняют код в отдельных вселенных Lua на поток. Таким образом, если Ваши библиотеки C не отказали бы, это неуязвимо для проблем, связанных с использованием потока. На самом деле понятие больше похоже на процессы и передачу сообщений, хотя только один процесс ОС используется.

Perl и Python делают. Ruby работает над ним, но потоки в Ruby 1.8 не являются действительно потоками.