OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 12 Декабрь, 2019 08:34

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 12 ] 
Автор Сообщение
СообщениеДобавлено: Суббота, 27 Июль, 2019 02:46 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1446
Добрый день, уважаемые коллеги.

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


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


Итак…


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

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

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






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

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


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…

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

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



Итак…

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

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

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


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 27 Июль, 2019 19:15 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 398
Откуда: Москва
Очень интересно и изложено блистательным языком. Прочитал с удовольствием. И второй раз прочитал с удовольствием. Такие вещи надо публиковать, т.к. они определяют точки, в которых происходит развитие.

Цитата:
по мере НЕОБХОДИМОСТИ вводить в строго детерминированную модель, средства недетерминированного поведения
хотелось бы еще примеров, ибо тут некоторое обобщение.

В плане развития активных объектов и каналов (Вы говорили об абстракциях, я немножко о реализации) на мой взгляд приоритетным являются:
- возможность реализации средств защиты информации (СЗИ). Это означает многопользовательскую ОС с изоляцией групп активных объектов разных пользователей друг от друга;
- возможность построения доверенных каналов связи, опять-таки отвечающих требованиям безопасности информации.
Абсолютно уверен, что этим гораздо полезнее заниматься, чем построением версий Linux на базе ядер, скачанных с http://www.kernel.org


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 28 Июль, 2019 20:04 

Зарегистрирован: Пятница, 22 Март, 2019 07:50
Сообщения: 39
Присоединяюсь к предложению опубликовать статью на других ресурсах. Очень хорошо написано.
Со своей колокольни предложил бы хабр - тогда многие увидят. Прямо в сердце отечественного мейнстрима так сказать. Но это автору решать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 29 Июль, 2019 11:40 

Зарегистрирован: Пятница, 22 Март, 2019 07:50
Сообщения: 39
Если есть опасения, что на Хабре примут как-то неадекватно статью - могу под своей учеткой опубликовать со ссылкой на авторство.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 29 Июль, 2019 13:36 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 864
Откуда: Казань
Данная тема касается во многом параллельного программирования. У меня есть своя точка зрения на многие изложенные здесь моменты. Многие эти моменты я рассказывал на Дне Оберона 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 потоках, тогда она будет работать быстрее и так же правильно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 29 Июль, 2019 16:33 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 975
Откуда: Киев
Rifat писал(а):
В частности, говорится про то, что должна быть детерминированность выполнения.
Wlad писал(а):
Тогда, как правильным подходом и решением был бы прямо противоположный путь: по мере НЕОБХОДИМОСТИ вводить в строго детерминированную модель, средства недетерминированного поведения, максимально ограниченные и обеспеченные механизмами безопасности.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 29 Июль, 2019 16:35 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 975
Откуда: Киев
D_S__ писал(а):
Присоединяюсь к предложению опубликовать статью на других ресурсах.
А на мой взгляд не стоит публиковать. В этих размышлизмах не так много по делу


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 30 Июль, 2019 00:50 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1446
Публиковать больше нигде не надо.
Если кто-то где-то выложит копии прошу содействия в удалении этих копий.
Прошу и здесь эту ветку всю вытереть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 30 Июль, 2019 13:35 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1343
Откуда: Украина, Киев
Wlad писал(а):
Прошу и здесь эту ветку всю вытереть.
Серьёзно?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 31 Июль, 2019 10:11 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1446
Ярослав Романченко писал(а):
Wlad писал(а):
Прошу и здесь эту ветку всю вытереть.
Серьёзно?

Я не понимаю, что происходит.
У меня костный язык или я как-то не так доношу свои мысли?
Один мой знакомый говорил, что если у кого-то во рту каша, то, значит, в голове у него - винегрет.
Но у меня есть сработавший критерий проверки того, что в моей голове не совсем винегрет - практика и выполненные проекты...
Я не понимаю, как донести до аудитории, если люди даже в процессе согласования определений, проявляют негибкость мышления (тем более - "на чужом полле"/"в чужом монастыре" они).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 31 Июль, 2019 12:31 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2638
Откуда: Россия, Ярославль
Вы просто не рок-звезда, вот рок-звезд слушают, цитируют, репостят, даже если они в депрессивном расстройстве под таблетками несут очередную чушь про то, что А это А. Обычных людей зачем слушать, обычные люди кто вообще такие, чтобы их слушать и тем более откуда у них право давать определения вещам?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Август, 2019 19:12 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 680
Сохранил на всякий случай, хотя букв слишком много для нашего суетливого времени.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 12 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot] и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB