Подтвердить что ты не робот

Стиль Erlang concurrency на языке программирования D

Я думаю, что стиль Erlang concurrency является ответом на экспоненциальный рост количества ядер. Вы можете подделать его с другими языками основного потока. Но решения всегда оставляют меня желать. Я не хочу отказаться от программирования с несколькими парадигмами (С++/D), чтобы переключиться на синтаксис Erlang draconian.

Что такое стиль Erlang concurrency:

От одного из авторов языка (Что такое модель Erlang concurrency на самом деле?):

  • Легкий concurrency.
    Дешево создавать темы и дешево поддерживать безумные номера.
  • Асинхронная связь.
    Потоки только обмениваются сообщениями.
  • Обработка ошибок.
  • Изоляция процесса.

Или из информированного блоггера (Что такое стиль Erlang Concurrency?):

  • Быстрое создание/уничтожение процесса
  • Возможность поддерживать → 10 000 одновременных процессов с практически неизменными характеристиками.
  • Быстрая передача асинхронных сообщений.
  • Копирование семантики передачи сообщений (share-nothing concurrency).
  • Мониторинг процесса.
  • Выборочный прием сообщений.

Я думаю, что передача сообщений D может выполнить большинство этих функций. Те, о которых я задумываюсь, являются " → 10000 одновременных процессов (потоков)" и "быстрое создание/уничтожение процесса".

Насколько хорошо D справляется с этими требованиями?

Я думаю, что для правильной поддержки их вам нужно будет использовать зеленые темы. Можно ли использовать функции передачи сообщений D с помощью библиотеки зеленых потоков?

4b9b3361

Ответ 1

Хранение по-умолчанию локально по умолчанию в D, поэтому ничто не делится между потоками, если оно специально не помечено как shared. Если вы помечаете переменную как shared, вы можете использовать традиционные мьютексы и условия, а также синхронизированные объекты и т.п. Для работы с concurrency. Однако предпочтительным средством передачи сообщений между потоками является использование средств передачи сообщений в std.concurrency и позволяет всем данным оставаться локально-потоковыми, но только при использовании shared, когда нужно. Все объекты, передаваемые между потоками с использованием std.concurrency, должны либо передаваться по значению, либо быть неизменными, поэтому обмен не происходит там, и он полностью потокобезопасен. Тем не менее, в настоящее время может быть немного больно получить неизменный ссылочный тип, который не является массивом (idup обычно облегчает работу с массивами), поэтому может быть немного неприятно передавать что-либо, кроме типов значений, или массивов (хотя, надеюсь, эта ситуация улучшится в скором времени, когда ошибки компилятора и стандартной библиотеки, относящиеся к const и неизменяемым, будут исправлены, а код больше const-correct).

Теперь, когда передача сообщений в D определенно приведет к более чистым и безопасным кодам, чем то, что вы получите на таких языках, как С++ или Java, оно построено поверх обычных потоков C (например, Linux использует pthreads), поэтому не имеет вида легких потоков, которые Erlang делает, и поэтому иметь дело с несколькими потоками не будет столь же эффективным, как Erlang.

Конечно, я не вижу причин, по которым более эффективная система потоков не могла быть написана с использованием D, и в этот момент вы могли бы получить эффективность потока, аналогичную эффективности Erlang, и она могла бы использовать API аналогично стандарту std.concurrency, но все стандартные потоковые материалы D построены поверх нормальных потоков C, поэтому вам придется делать все это самостоятельно и в зависимости от того, как вы его реализовали, и в зависимости от того, как именно thread-local/ shared материал обрабатывается компилятором и druntime, может быть сложно получить систему типов, чтобы обеспечить, чтобы все было поточно-локальным с вашими "зелеными" потоками. Я боюсь, что я не знаю достаточно точно о том, как реализуется shared или как "зеленые" потоки работают, чтобы точно знать.

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

Ответ 2

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

Как несвязанная сторона примечания, довольно круто, что D достаточно низкоуровневый, чтобы вы могли написать эту фреймворк в нем и достаточно высокого уровня, чтобы быть убедительным языком для написания ваших веб-приложений в дополнение к структуре, Другие популярные языки с подобными структурами (node.js, Ruby EventMachine, сопрограммы в Python и Go) не могут конкурировать с D в низкоуровневых системах кодирования. Другие популярные языки с аналогичными системами программирования (C, С++) не могут конкурировать с высокоуровневым кодированием приложений.

Я новичок в D, но я должен сказать, мне нравится то, что я вижу.

Ответ 3

Из всего, что я знаю о D: его инфраструктура передачи сообщений построена поверх своих потоков. Если базовая библиотека потоковой передачи является оберткой на потоках ОС, мало шансов, что concurrency в D достигнет величины ( → 10000) Erlang. Кроме того, D не обеспечивает неизменность объектов, поэтому их легко повредить. Итак, Erlang - лучший выбор для тяжелых concurrency. Вероятно, вы можете написать материал concurrency в Erlang и остальную часть проекта в D. Тем не менее, можно иметь эффективные зеленые потоки на C-подобных языках (С++, D и т.д.) - взгляните на Protothreads и ZeroMQ. Вы можете реализовать очень эффективные фреймворки обмена сообщениями, используя их, и называть их через C-образную прокладку или непосредственно из D.