Если типичный императивный язык программирования был в начальной задумке однопоточным, то наивное добавление в него многопоточности не может быть осуществлено без слома совместимости, так как нарушает фундаментальное свойство, гарантирующее неизменность доступных переменных при отсутствии их изменений со стороны самого потока. Приёмы работы с данными, которые были совершенно приемлемы в однопоточности, могут оказаться неадекватными в многопоточном. Такой слом в языке не является чем-то совсем недопустимым, если сама платформа зарождалась в такой среде и накопление кода всегда происходило с учётом этой особенности. Но даже в этом случае достижение правильности кода избыточно перекладывается на плечи программиста с сопутствующими результатами. Такой подход неприемлем для языков, создаваемых не только для того, чтобы не мешать, но и для того, чтобы помогать. Что можно предложить для них?
четверг, 10 ноября 2022 г.
Подписаться на:
Комментарии (Atom)
Архив блога
Создал репозиторий с содержимым этого блога — https://github.com/Vostok-space/blog . Также, добавил его в ipfs, где он напрямую доступе...
-
Если нужно использовать модули, параметризированные по ряду объявлений (generics, шаблоны), то в оригинальном Oberon, как и в Modu...
-
Добавлено свойство проверяемости при работе с низкоуровневыми адресами в процедурах из SYSTEM — ADR, BIT, GET, PUT, COPY. Прове...
-
Воспользовавшись тестом на производительность с форума oberspace , реализованного для разных языков, проверил свой транслятор . ...