Могу ли я игнорировать безопасность потоков при программировании на Erlang?

Question

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

Может ли использование такого функционального языка, как Эрланг, полностью избавить меня от этой проблемы?

Answer 1

в Erlang единица состояния выполнения - это не поток, а процесс.да, это легкий процесс, реализованный поверх потоков;но это больше похоже на процесс, чем на поток.

Суть в том, что процессы не разделяют состояние, они передают сообщения;в то время как потоки разделяют все по умолчанию и вынуждены выполнять арбитраж, чтобы избежать хаоса.

, таким образом, вам не нужна безопасность потоков, так как вы не работаете с потоками.

Answer 2

Хавьер прав.

Тем не менее, я хотел бы просто добавить кое-что, как это поймало меня раньше.Если вы работаете со встроенным драйвером или nif, он может больше не быть потокобезопасным.Это кажется очевидным, поскольку драйвер или nif будут использовать код на C или C ++, но стоит упомянуть.Таким образом, вы не можете полностью игнорировать безопасность потоков только потому, что используете Erlang.

Answer 3

Нет.См. Актеры Эрланга Стиля все о блокировке .Гораздо проще добиться безопасности потоков на функциональном языке, но вам нужно об этом подумать.

Я только начал изучать безопасность потоков.Это заставляет меня писать код более защищенно, возможно, слишком оборонительно.

Обратите внимание, что в этом случае очень вероятно, что вы все еще ошибаетесь.Параллельный общий ресурс очень, очень трудно получить правильный во всем, кроме самых тривиальных примеров.

Answer 4

Нет, вам все еще нужно учитывать безопасность потоков в Erlang, но проблемы гораздо проще решить.

Я прочитал статью , в которой автор указал, что ваше сообщение APIможет вызвать проблемы с многопоточностью.Пример вращался вокруг банковского счета.Его начальный API сообщений имел операции GET и SET.Какой-то код, который хотел внести 100 долларов, получит текущее значение, добавит к нему 100, а затем установит результат.Конечно, это работает, только если один процесс обращается к банковскому счету.Как только два процесса манипулируют балансом, все ставки отключены.

Его решение было изменить API сообщений на DEPOSIT и WITHDRAW (он фактически использует одно сообщение - UPDATE - но вы поняли идею).Это заставляет взаимодействие принимать атомарную семантику - процесс прослушивания будет обрабатывать только один депозит или снятие за раз, и будет блокировать другие запросы, пока первый не будет завершен.

Стоит отметить, что эта проблема по сути та жекак проблема с общей памятью.(Если мы используем сообщения GET и SET для взаимодействия с процессом, мы, по сути, создали некоторую общую память).Другой блоггер сравнивает ets с общей памятью .Однако, пока вы понимаете, где вы ввели конструкции, подобные разделяемой памяти, и регулируете доступ к этой разделяемой памяти, у вас не должно быть проблем с многопоточностью (кроме тупиков, конечно).

Answer 5

Отказ от ответственности: я практически не знаю Эрланга.Возьмите мое мнение с крошкой соли.

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

Но я не знаю, является ли Erlang чисто функциональным (вики подразумевает иное, так что, думаю, это не так).Возможно, он использует другие средства достижения безопасности потоков.В любом случае, его структуры данных (в основном «исключительно») неизменяемы и, таким образом, по своей природе поточно-ориентированы.И, будучи функциональным языком, по крайней мере идиоматический код Erlang не будет использовать (muc? Any?) Глобальные переменные, а вместо этого будет использовать чистые функции.Это потокобезопасные.Но вещи ввода / вывода все еще могут быть проблемой ... если программа Erlang читает и записывает файл одновременно, такой код вряд ли будет поточно-ориентированным.Но большую часть времени вы будете в порядке благодаря неизменным структурам данных и тому подобному.