Данная тема касается во многом параллельного программирования. У меня есть своя точка зрения на многие изложенные здесь моменты. Многие эти моменты я рассказывал наДне Оберона 2018.

В частности, говорится про то, что должна быть детерминированность выполнения. На это хочется ответить цитатой Дейкстры из книги "Дисциплина программирования":
> -- Цитата:
> В этой книге я буду — и это может оказаться одной из ее отличительных особенностей— рассматривать недетерминированность как правило, а детерминированность как исключение: детерминированная машина будет рассматриваться как частный случай недетерминированной, как конструкция, для которой справедливо свойство 4’ а не только более слабое свойство 4. Такое решение отражает коренное изменение в моем мировоззрении. В 1958 г. я был одним из первых, кто разрабатывал базовое программное обеспечение для машины с прерываниями ввода-вывода, и невоспроизводимость поведения такой во всех отношениях недетерминированной машины явилась горестным обстоятельством. Когда впервые была предложена идея прерываний ввода-вывода, меня настолько пугала сама мысль о необходимости разрабатывать надежное программное обеспечение для такого неукротимого зверя, что я оттягивал принятие решения о допущении таких прерываний по крайней мере в течение трех месяцев. И даже после того, как я сдался (мое сопротивление сломили лестью), чувствовал я себя весьма неуютно: ведь ошибка в программе способна вызвать несуразное поведение системы, столь сходное с невоспроизводимым машинным сбоем. Кроме того,— и это в то время, когда для детерминированных машин мы все еще полагались на "отладку",— с самого начала было совершенно очевидно, что тестирование программ оказывалось теперь совсем непригодным средством для достижения должного уровня надежности.В течение многих лет впоследствии я относился к невоспроизводимости поведения недетерминированной машины как к добавочному осложнению, которого следует избегать любыми способами. Прерывания были для меня не чем иным, как злыми кознями инженеров по аппаратуре против бедных разработчиков программного обеспечения. Из этого моего страха родилась дисциплина "гармонически взаимодействующих последовательных процессов". Несмотря на ее успех, мои опасения сохранялись, поскольку наши решения — хоть бы и с доказанной правильностью — представлялись частными решениями проблемы "укрощения" (именно так мы это воспринимали!) конкретных видов недетерминированности. Основанием для моего страха было отсутствие общей методологии.С тех пор два обстоятельства изменили картину. Первое возникло с пониманием того, что даже в случае полностью детерминированных машин полезность тестирования программ оказывается сомнительной. Как я уже много paз говорил и во многих местах писал, тестирование программы может вполне эффективно служить для демонстрации наличия в ней ошибок, но, к сожалению, непригодно для доказательства их отсутствия. Другим прояснившимся тем временем обстоятельством явилось обнаружение необходимости того, чтобы всякая дисциплина проектирования должным образом учитывала тот факт, что само проектирование конструкции, предназначенной для какой-то цели, тоже должно быть целенаправленной деятельностью. В нашем конкретном случае это означает естественность предположения, что отправной точкой для проектных рассмотрений будет служить заданное постусловие. В каком-то смысле мы будем "работать вспять". Действуя так, мы обнаружим, что весьма существенным оказывается следование из свойства 4, тогда как от равенства из свойства 4’ мы получим очень мало пользы.Как только мы разработали математический аппарат, позволяющий проектировать недетерминированные конструкции, достигающие цели, недетерминированная машина перестает нас пугать. Напротив! Мы научимся даже ценить ее как важную степень на пути разработки проекта в конечном итоге полностью детерминированной конструкции.

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

При рассмотрении различных видов параллельности многие люди рассуждают субъективными понятиями. Для одних одно проще, а для других другое. Если же в качестве основы взять математический аппарат для доказательства корректности различных видов параллельности, то субъективности становится гораздо меньше. Так как одни виды параллельности доказываются существенно сложнее, чем другие. Одним из наиболее простых видов параллельности является подмножество CSP (Хоара), о котором пишут Krzysztof R. Apt (и др.) в книге "Verification of Sequential and Concurrent Programs". В отличие от CSP Хоара, где команды приёма и посылки сообщений могут располагаться в любом месте процесса, в подмножестве CSP эти команды могут располагаться в строго фиксированном месте. Это делается умышленно, для того, чтобы была возможность свести параллельную программу к недетерминированному циклу Дейкстры и в соответствие в математическим аппаратом, о котором говорил Дейкстра, доказать корректность программы.

И у меня есть определенный скепсис по отношению к Active Oberon, так как тип параллельности, который он использует, относится к тому типу параллельности, при котором не так-то просто доказать корректность программы.

У меня есть определенные наработки по имплементации подмножества CSP, о котором говорит Apt на Oberon-07 (язык здесь не так важен, а важен сам подход). Для того, чтобы использовать этот подход необходимо, конечно, изменить свой подход к программированию, то есть проектировать программу так, чтобы она соответствовала подмножеству CSP.

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