Добрый день, уважаемые коллеги.

Не то, что бы меня сильно потянуло растечься мыслью по древу, но, время от времени требуется некоторое подведение итогов. Хотя бы из-за разного рода гештальтов. К тому же, события последнего времени, будто бы специально акцентировали внимание на бренности человеческого бытия и скоротечности жизни.


В этом месте можно/нужно было бы, “по закону жанра” сразу начать с определений...
Но, начнём с исторического экскурса. Именно через него попытаемся понять с чем мы имеем дело, как оно появилось, во что развилось и под действием чего приобрело сегодняшние общепринятые черты и признаки.


Итак…


Природа не имеет ни иерархий, ни слоёв семантики и логики.
Вы - прочитали верно.
А отреагировали, скорее всего, неправильно.
У подавляющего большинства программистов (и ДАЖЕ - математиков), прочитавших первое предложение этого абзаца, возник широчайший спектр негативных реакций и совокупности лексических единиц для возражения автору и характеристики последнего…

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

(На мой дилетантский взгляд (естественно могущий оказаться полной чушью), наиболее близко к “порядку” и “иерархичности” чего-то, что находится вне нашего механизма отражения внешнего мира, приблизились те специалисты, кто занимается фракталами. Но это - тема отдельного разговора. Пока же, видимо, стоит отметить, что именно свойство “фрактальности”, даёт тот “клей” и “механизм сцепки”, позволяющие увидеть разделение рассматриваемых частей внешнего мира в какой-то стройности и “расположенности по слоям”.
Опять же - саму природу и свойства “фрактальности” во внешнем мире мы НЕ знаем, НЕ понимаем и НЕ представляем. Мы лишь откопали нечто в механизме организации нашей мыслительной деятельности, что помогает нам строить модели и эти модели оказываются удивительным образом адекватны и применимы к огромному количеству феноменов во внешнем мире.)






Копать детально историю отрасли я не собираюсь.
Пробежимся по основным этапам и направлениям тематик и работ в ИТ.

С момента зарождения отрасли ИТ большинство задач сводилось к чисто вычислительным, «расчётным» проблемам. Характерными чертами программ той эпохи были:


1) детерминированность, линейность последовательности этапов решения задачи (ввод-обработка-вывод)

2) абсолютная зависимость/привязанность к устройствам ввода/вывода конкретной вычислительной системы

3) «нацеленность» на решение конкретной задачи или класса задач

Очень часто системы и ПО продавались/поставлялись заказчику вместе, как нечто нераздельное и единое.

С течением времени возникла потребность:
- увеличивать и разнообразить набор решаемых им задач
- расширять номенклатуру подключаемого периферийного оборудования

В процессе разрешения этих требований произошло естественное разделение ПО на два больших класса:
- системное и
- прикладное.


Всистемном ПОсразу же произошло выделение нескольких типовых вещей для обеспечения работы программ пользователей:
- процессы/задачи
- файлы и файловые системы
- подсистемы ввода/вывода

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

Переход к поддержке параллельности исполнения нескольких программ был предсказуем.
Причины:
- высокая стоимость вычислительных ресурсов
- высокий спрос на компьютерные вычисления со стороны массы пользователей
- автоматизация управления производственными процессами и предоставление информационно-справочных услуг.

Не все из вышеперечисленного требует перехода к параллельности исполнения нескольких задач пользователя (для «расчётных» задач хватало и, так называемой «пакетной обработки», когда программы запускались «на прогон» последовательно друг за другом). Но обеспечение одновременности доступа пользователей к информационно-справочным ресурсам уже требует принятия дисциплины взаимодействия процессов их (псевдо)одновременного исполнения и сохранения корректности данных, к которым эти пользователи получают доступ.
Решение этих задач опиралось на, вышеупомянутый, ограниченный круг понятий и требовало лишь аккуратности и последовательности в реализации механизмов ОС и тех или иных принятых стандартов при работе с периферией.
Семантическая же «мощность» и «наполнение» были устоявшимися и достаточно узкими (как и, собственно, набор задач системного уровня).


В областиприкладного (пользовательского) ПОситуация складывалась совершенно противоположным образом.

Сама суть работы разработчиков прикладного ПО состоит в придумывании множеств сущностей своих прикладных областей с произвольно определяемыми смысловым наполнением и поведением. Вариативность тематик, типов и видов реализуемых моделей из прикладных областей — совершенно безгранична и имеет только врЕменные ограничения на память и быстродействие используемого вычислительного механизма.



Казалось бы, свобода самовыражения на таком, исключительно гибком, инструменте, позволяющем проверять на опыте ЛЮБЫЕ умозрительные модели, в сочетании с проникновением компьютеров во все отрасли производства и области человеческой жизни, должны были дать совершенно фантастические результаты (фантастами даже строились некие графики-таблицы с предсказаниями когда и что фантастическое должно было стать реальностью)...

Однако, уже начале 70-х годов начал подниматься вопрос о «кризисе разработки ПО»…

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


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

Идеал разработчиков сводился к фразе, популярной в среде Хаскель-программистов:

«Если программа успешно откомпилировалась, значит она будет правильно исполняться.»

(Это высказывание — единственное, что взято из мира функционального программирования для этого “эссе”. Далее рассматриваются проблемы мира, основанного на сугубо императивном базисе.)



Цели проектирования любой программы сводятся к:

1) созданию функциональной копии реально существующей системы
2) получению новой системы с затребованными функционалом и характеристиками

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

Второй случай — конструирование согласованного цельного поведения системы при реализации требуемого функционала.


При проектировании приходится иметь дело со статическим и динамическим аспектами моделирования.

Статический аспект— моделирование внутренней структуры, и внешних связей объектов, составляющих систему. Реализуются через описание структур данных и переменных, значения которых описывают и поддерживают описание/толкование таких связей и структур.

Динамический аспект— совокупность описаний взаимодействия объектов друг с другом.
По сути, динамика описывает сценарии/«эпизоды»/правила взаимодействия объектов модели друг с другом.



Постатическому аспектуотраслью накоплен богатый опытный материал.

По сути, весь этот опыт отображается в книгах и трудах, в названиях которых фигурируют обороты, типа «алгоритмы и структуры данных».

Здесь отрасль прошла через:
- структурное программирование,
- программирование с использованием абстрактных типов данных
- … и пришло сейчас к ООП.

Распространение ООП ничего, по сути, не изменило по сравнению с АТД, за исключением синтаксических нюансов оформления семантики кода. Оба подхода внесли значительный вклад в возможность повышения проектировщиками степени модульности (понижения степени связности и зависимости частей) проектируемых систем.



Однако, описанию «поведенческих свойств» (динамический аспект) моделируемых сущностей уделялось недостаточно пристальное внимание.

Такое положение сохранялось достаточно длительное время в «мейнстриме».
Например, что-то относящееся к параллельности исполнения, стало упоминаться в С и С++ только в последних стандартах.


«Поведенческие нюансы» представлялись вторичными и рассматривались опосредованно (через свойства и возможности конкретных сред исполнения, библиотек или ОС, иногда — языка, если последний обладал таковыми).

...Что было само по себе удивительным, потому, что ещё в первом ОО языке — Симуле (это — вторая половина 1960-х) уже были представлены средства описания «сценариев поведения сущностей».

И в Смолтоке (1970-ые и 80-ые годы) последовательности шагов исполнения — «блоки кода»  — являлись объектами (как и ВСЁ в этом языке) и имели возможность манипулирования их свойствами и активностью (создание, запуск, останов, уничтожение). По своим свойствам и возможностям они уже тогда использовались как современные замыкания, и блоки кода отложенного исполнения с сохранением контекста.

Тем не менее, в широко распространённых языках, поведение объекта рассматривалось лишь как внутренние действия объекта по внешним запросам состояния объекта + реакция на изменение внешнего окружения объекта.

Отсутствовала возможность формализовать и описать сложные («многостадийные/многовариантные») взаимодействия с внешними объектами.

Языки не предоставляли свойств и средств определения и управления такими актами взаимодействия.

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


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


Само ООП корнями уходит именно в системы моделирования и симуляции работы сложных систем большой размерности в областях:
- проектирования больших производств и предприятий
- проектирования и оптимизации сетей транспорта
- оптимизации процессов и протоколов в управленческом аппарате уровня отрасли или страны
- моделирования боевых операций различного масштаба
- моделирования поведения биологических систем
- моделирования физико-химических процессов при рассмотрении систем с огромных количеством взаимодействующих частей (конечные элементы в механических конструкциях, взаимодействия молекул в химических реакциях, моделирование реакций на атомном уровне, расчёты поведения веществ и сред в различных фазовых состояниях на многомерных сетках)
- моделирования процессов в социальных и социотехнических системах
- моделирования распространения эпидемий
- предсказания погоды…


Понадобился механизм моделирования действий объектов предметной области.
И — часто — одновременно на многих вычислительных устройствах..

Сейчас обычно никто не создаёт специализированные машины для исполнения какой-то одной задачи.
Это было и остаётся слишком дорогим.

Отрасль пошла по пути универсализации компьютеров и операционных систем.

Произошла относительная стабилизация и стандартизация понятий, подходов и механизмов исполнения нескольких задач в (псевдо)параллельном режиме.
Были наработаны библиотеки и системные утилиты, позволяющие следить за исполняющимися сущностями операционной системы и управлять ими.
Обычно такие сущности именуют процессами и потоками.
Есть ещё нити, волокна и файберы, «зелёные», «легковесные» потоки.
Но нас сейчас это разнообразие классов и названий не интересует.
Значительным успехам в отрасли мы обязаны, в том числе и жёсткому ограничению предметной области и абстрагированию при создании операционных систем. Наряду с универсализацией других двух абстрактных сущностей — «файла» и «пространства имён», отрасль получила инструментарий для создания всего необходимого спектра систем для любого потребителя.

Но.

В реальной жизни мы не работаем только с файлами, процессами и пространствами их имён…

Конечно, очень много задач можно свести к базису, в который входят перечисленные понятия системного уровня.
И многие задачи были успешно решены после такого приведения и трансформации понятийного аппарата и словаря первоначальной задачи...
Но, по сути, решалась уже не первоначальная задача.
А — переделанная и ПОДОГНАННАЯ ПОД СРЕДСТВА РЕАЛИЗАЦИИ.
То есть, не имея адекватных средств для описания ПЕРВОНАЧАЛЬНОЙ задачи, мы преобразовали первоначальную задачу под понятийный аппарат совершенно другого класса задач.

Очень часто программирование как раз и представляет собой набор «сшивок» понятий из разных областей и из разных уровней, для описания и интерпретации понятий и поведения из одной предметной области понятиями и поведением из другой предметной области.
Ситуация стала настолько стандартной и принятой, что корифеям и столпам ИТ-мира стоило очень больших усилий, что бы указать на это состояние отрасли и ненормальность принятых подходов и приёмов труда при реализации программных систем.


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

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

Это мы говорим про прикладное ПО.

В системном ПО исполнимая сущность, изначально, представлялась некоей «секцией/сегментом кода» в рамках процесса.

В последнее время такой «сегмент кода» стали именовать «потоком» (thread).

Изначально практически все ОС имели процессы с одним «потоком».
Однако, затем стало возникать «проникновение» прикладного ПО на системный уровень.
Проникновение - через требование на реализацию с «помощью чего-нибудь» нескольких исполняющихся сущностей в рамках одного процесса.


Снова «открутим» часы ИТ отрасли немного назад.

Изначально исследователями и практиками, кто занимался разработками, было найдено несколько универсальных оптимальных решений в ИТ, вокруг которых возможно построение оптимальных и надёжных систем.

Было вычислено оптимальное основание для системы исчисления в компьютерах (троичная).

Была найдена оптимальная архитектура «элементарного вычислителя» (стековая, нуль-адресная архитектура: АЛУ + 2 стека + массив памяти произвольного доступа).

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


Были и есть прекрасные образцы конструирования таких ОС и ядер (L4, Minix (3), QNX до версии 6.х).

Но их «оптимальность» была обоснована С ТОЧКИ ЗРЕНИЯ СИСТЕМНОГО УРОВНЯ для представления механизмов и конструкций таких «элементарных исполнимых сущностей» для прикладного уровня.

Именно из этих исследований и выводов появились надежды на чудесные свойства микроядерных ОСей.
Но!
Опять возникает проблема, упомянутой выше, «трансформации задачи».



Во многих системах, чисто из требований самой задачи, нам НЕОБХОДИМ запуск нескольких исполняемых сущностей в рамках этой задачи.

И приходится имитировать «многопотоковость», вводя некоторые механизмы и средства, которые ломают изначальную стройность «оптимальной архитектуры».

Кроме чисто «эстетических изъянов» в архитектурных решениях таких систем, там «ломаются» и средства разделения адресных пространств (разрушение основного средства надёжности и безопасности) и возникают неоправданно длительные задержки на обеспечении передачи данных между такими «потоками» (прохождение данными большого числа промежуточных логических уровней в системе).

Естественным было ожидать момента, когда отрасли будут представлены решения с возможностью запуска множества потоков в процессах.

И они появились.


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


Основная проблема была в том, что программирование, само по себе основывается на использовании детерминированных решений и механизмов.

А потоки являются строго недетерминированным механизмом.
[Sutter & Lee]
Опуская чисто теоретические посылы, выкладки и заключения,сложившийся подход в обеспечении многопотоковых приложений нехорош тем, что для получения правильно (или — хоть как-то) работающей системы, мы вынуждены в исконно недетерминированную систему вводить механизмы, повышающие её детерминированность.
Тогда, как правильным подходом и решением был бы прямо противоположный путь: по мере НЕОБХОДИМОСТИ вводить в строго детерминированную модель, средства недетерминированного поведения, максимально ограниченные и обеспеченные механизмами безопасности.


Многие исследователи и разработчики, не осознавая чётко этой проблемы, «инстинктивно», предлагали другие архитектурные решения для повышения уровня детерминизма моделей проектируемых систем.
При этом достигались достаточно успешные и интересные решения.
[Oberon & Plan 9]


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




Кроме упомянутой проблемы (использование строго недетерминированных механизмов для реализации детерминированных подходов), существует ещё одна...

...СамаяГлавная Беда...

...Архитектурного плана.
Проектировщики смешивают понятия из разных логических уровней представления системы.

На уровень предметной области «поднимаются» понятия системного уровня.
Происходит смешение семантик и уровней логики оперирования сущностями.

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

Для нивелирования этой Главной Беды было осуществлено множество попыток «облагородить» представление системных механизмов и элементов многозадачности, обернув их классами.
Можно перечислить большое количество таких библиотек классов, многие из которых даже считаются вполне успешными, удобными и получили широкое распространение.

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


Эту проблему заметили и ОСОЗНАЛИ многие разработчики и исследователи.
Начался поиск новых, более высокоуровневых средств и механизмов для выражения параллельности и обеспечения корректности доступа к совместно используемым данным.

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

Теорию и идеи разработал Хоар, а первым описал и реализовал в Concurrent Pascal Хансен.
С тех пор во многие языки были добавлены элементы реализации мониторов на уровне экземпляров объектов.
Реализации ООП в языках стали естественным способом воплощения «охраняемой/курируемой монитором совокупности данных с монопольным доступом».

Главная заслуга мониторов состоит в том, что пользователь и/или разработчик системы получает УНИВЕРСАЛЬНЫЙ семантический и логический инструмент, позволяющий отбросить необходимость помнить о- и оперировать сущностями более низких уровней системы.

Механизм мониторов уже - не отдельная смысловая сущность в проектируемой системе, а - выражаетсвойствообъекта обеспечения синхронизированного доступа к своим внутренностям через интерфейсные методы.

Из-за высокого семантического уровня мониторов, естественным образом нас перестаёт волновать внутренняя реализация механизмов работы мониторов и мы просто выкидываем понятия мьютексов, условных переменных, сигналов и событий из предметной области.



Оставалась задача найти средство представления и реализации исполнимых сущностей такого же уровня лёгкости восприятия и «незаметности», как и мониторы.

И на этом шаге у многих исследователей возникли непреодолимые трудности.

В большинстве сегодняшних решений (библиотеках и языках) остаются отголоски явной «потоковости» подходов. Во множестве библиотек мы постоянно встречаем *Thread* класс, который всё также имеет виртуальный метод run() или execute().
В некоторых языках и библиотеках наработаны даже архитектурные решения для использования такой «облагороженной» обёртки над системной сущностью, и — приёмы применения объектов, классы которых реализуют интерфейсы с названием вроде Runnable.

В чём причина такого торможения?
Есть основания полагать, что авторы-реализаторы этих библиотек и языков просто не до конца прониклись и овладели идеями, концепциями, подходами и методологиями ОО-мира.
Там, где этим идеям и подходам следовали качественно, в комплексе и — до конца, решения получались компактными, логичными, выверенными и без раздувания «вспомогательного» кода и навороченных, распухших диаграмм «темплейтов проектирования».

Примерами такого последовательного исполнения решений в духе ООП могут послужить два языка, опять-таки вышедшие из лаборатории Вирта: Active Oberon и Zonnon.

Первый использовался для написания ОС следующего поколения (AOS/bluebottle/A2).
Мониторы Хоара-Хансена реализованы в AO через блоки эксклюзивного (на уровне экземпляра класса) исполнения.
Исполнимые сущности выражены в виде АКТИВНОСТИ экземпляра объекта.
Что бы было понятно в привычных терминах, активность — это поток, который стартует в контексте конкретного экземпляра какого-то класса.
По сути дела он являет собой представление «жизненного цикла» экземпляра конкретного класса, «сценарий» его жизни.

Именно такое сочетание элементов обеспечения эксклюзивности доступа и определения активности завершает долгий путь получения по-настоящему активных объектов.
“Активный объект”- теперь — не соглашения на уровне шаблона проектирования с прикреплённым ярким названием и не совокупность обёрток над привычными низкоуровневыми элементами.
Теперь ООП выходит на более высокий, чем ранее, семантический и логический уровень проектирования, избавляясь от груза необходимости учёта и рассмотрения сущностей, НЕ относящихся к рассматриваемым уровням проектирования системы.

Наиболее ярким примером использования Active Oberon является ОС AOS/bluebottle/A2.
В этой системе ВЕЗДЕ (от драйверов и элементов ядра и — до прикладных подсистем) всё реализовано с помощью активных объектов.
Единственная не-ОО часть это — начальный загрузчик (где-то в 700 строк), который проверяет и инициализирует «железо» и формирует стартовый набор активных объектов ядра и драйверов.

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



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

Возвратимся опять к динамическому аспекту функционирования ОО систем — взаимодействию между активными объектами.

Зададимся совершенно тривиальным вопросом:а что такое интерфейс класса?

Первый ответ, который возникает в сознании у большинства разработчиков, это — совокупность заголовков общедоступных методов класса (для случая клиента класса по наследованию сюда добавляются защищённые методы, но этот случай — немного из другой области).

Для «разовых», «атомарных» операций над экземпляром такой ответ вполне удовлетворителен.

А если оба объекта — активные и вступают в диалог с многочисленными актами обмена данными с переходом по внутренним состояниям?

В сложившейся практике программирования наработано множество подходов и методологий построения инфраструктуры и наборов объектов для обеспечения такого «многостадийного» взаимодействия.
Прокси-объекты, глубоковложенные обратные вызовы, замыкания, очереди запросов и результатов с идентификацией корреспондентов, стадий обменов или времени момента посылки-приёма, идентификаторами фрагментов «сообщений»…
Особенно это всё широко распространено при взаимодействии объектов через сети или по каналам через границы процессов.
И — опять — очень часто мы будем иметь «удовольствие» от смешения уровней.
Иногда верхний уровень вынужден разбирать поля сообщения со смыслом из более низких уровней.
И — наоборот, часто нижние уровни должны как-то иметь представление о состоянии объекта более высокого логического уровня, кому передаётся «пакет» после приёма, или от кого пришёл пакет для передачи.
Здесь слово «должны» обозначает не общий подход в этих взаимодействиях, а — вынужденность вследствие принятых проектных решений авторами библиотеки или класса.

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

Как было указано, такое понятие возникло давно и было названо «каналом».

Разновидностей каналов было создано много.
В общем каналы имели главные характеристики: одно- и двунаправленные, блокирующие и неблокирующие.

Но, дисциплина обмена по каналу продолжала оставаться в объектах, которые канал связывал.
Собственно эта дисциплина была обусловлена «этапами», через которые проходили «клиент» и «сервер» при многостадийном взаимодействии по данному каналу.
Практически мы имели каналы, тип/класс которых (если говорить в терминах ООП), напрямую выходил изсовокупности актов взаимодействия между клиентами данного объекта и самим объектом.

Получается, что мы, каким-то образом зная, какой набор передач инициируется клиентом при запросе на сервер, уже можем знать какая последовательность двухсторонних обменов данными  произойдёт на канале.

Появляется возможность «перепоручить» рутинные проверки «синтаксиса» обмена по каналу от объектов, которые связывает канал, на некую логику, реализованную в объекте канала. Именно эта идея была реализована в дальнейшем развитии языка Active Oberon — Zonnon

Следует также упомянуть совершенно экзотические реализации многозадачности на уровне «железа».

Первый случай это - процессор Propeller (Parallax).
Он представляет собой восьмиядерный процессор, в котором многозадачность обеспечивается параллельной работой всех восьми ядер над собственными блоками памяти и связь, через шину, попеременно подключающую к каждому из ядер «карусельно» общую, на все ядра, память.

Второй случай это - микроконтроллеры американской фирмы GreenArrays.
Они представляют собой асинхронные ФОРТ-ядра, упакованные на кристалле в прямоугольную матрицу.
Каждое из ядер имеет четыре соседа (СЮЗВ), с которыми оно обменивается данными по асинхронным блокирующим «каналам»-интерфейсам.
Ядра на периферии матрицы — специализированные, обычно реализуют стандартные интерфейсы, типа I2C, SPI, U(S)ART…

Характерной чертой обоих случаев является чрезвычайно низкое (особенно во втором случае) энергопотребление и ОТСУТСТВИЕ СИСТЕМЫ ПРЕРЫВАНИЙ.

“Минусом” таких архитектур и решений является необходимость изменения парадигм в подходах к проектированию и программированию на них.



Итак…

Отрасль прошла долгий путь определения и реализации формализмов для выражения проектных решений.
Сегодняшнее состояние очень противоречиво и хаотично.
Происходит это из-за совершенно необоснованного и дичайшего смешения (даже на уровне мейнстрим подходов, решений и средств реализаций) уровней представления проектируемой системы и неосознания проектировщиками такого положения. У большинства разработчиков НЕТ адекватных средств для своих разработок. А те, что есть - есть нагромождение упомянутых ошибочных штучек. Собственно и сам размер предлагаемых средств - как раз является свидетельством и следствием изначальной ошибочности при их проектировании и разработке.

Однако, есть одно направления разработки формализмов, где достигнуты достаточно серьёзные и необычные успехи. Ну, вы - всЕ поняли…

Именно появление языков Активный Оберон и Зоннон ознаменовали огромную веху в языкостроении. Наконец получен подход в проектировании и, поддерживающие его, языковые средства разработки, идеально, логично и органично объединяющий и соединяющий два мира программирования ООП и параллельность.


Собственно, теперь, ООП и многопоточное программирование - только частные (часто - избыточно переусложнённые) случае модели параллельности, принятые в АО и З.

В АО и “объектность” и “ параллельность” обрели свои завершённые логические формы и законченность и связность в плане представления статических (модульность) и динамических (параллельность жизненных циклов сущностей предметной области) аспектов моделей проектируемых систем.
И эти же свойства перестали “перегружать” отображения решений в ПРЕДМЕТНЫХ областях, перейдя из множества дополнительных, чуждых предметным областям, сущностей, в область СВОЙСТВ объектов предметной области. Это кардинальным образом изменило весь спектр подходов к проектированию и отображению результатов проектирования в языковых конструкциях (а, соответственно, и “акцентов в работе” компиляторов этих языков).
Даже “эмулирование” подходов к проектированию и языковых конструкций Активного Оберона в языках, выражающих совершенно чуждые ему модели памяти и среды исполнения, позволяет достигать кардинального улучшения проектируемых систем в плане трудозатрат, тестопригодности, логичности и ясности представления системы и надёжности работы готовой совокупности исполнимых частей.