Что делает Erlang подходящим для мягких приложений реального времени?

Некоторый фон

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

Оказывается, что обе эти функции удивительно сложно объединить, главным образом из-за одного конкретного ограничения: код в реальном времени не должен динамически выделять память.

Мой язык должен облегчить реализацию чего-то вроде этого:

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

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

Erlang часто рекламируется как подходящий для систем реального времени. Я понимаю, что Эрланг никогда не запрещает выделение памяти. Если бы я сделал то же самое, это избавило бы от многих проблем за счет введения недетерминированной синхронизации в коде, который выполняет это распределение.

Вопрос

Так что же делает Erlang такой хорошей подгонкой? Реализует ли он специальные приемы, чтобы обойти проблемы, вызванные распределением памяти, или он полностью игнорирует проблему? Требуется ли другой подход в реальном времени?

Пример для иллюстрации вопроса

Давайте предположим, что мы пишем синтезатор на Erlang, который должен производить 64 сэмпла каждые 50 миллисекунд, иначе в звуке есть трещины и трещины. Предположим также, что когда я перемещаю некоторый ползунок по строке, небольшой объект (скажем, список или кортеж, содержащий имя и новое значение параметра) должен быть отправлен из процесса графического интерфейса в аудиопроцесс, где копия создана. Это потребовало бы динамического выделения памяти. Как Erlang поможет мне убедиться, что это распределение не задержит мои аудио вычисления?

Ответы на вопрос(4)

Ваш ответ на вопрос