OberonCore

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



не нужно никаких сценариев. поскольку общего, даже приблизительно сценария для обьекта-заглушки, старающего сэмулировать пропавший удаленный реальный обьект нет. либо такие заглушки нужно писать руками, и предоставлять как реализацию актера, так и реализацию "глухого актера". лишнее это.
просто нужно уметь проверять доставлено ли ваше сообщение, у сообщения должны быть методы -
bool is_received(); //неблокирующая проверка доставки
bool wait_is_received(timeout);//блокирующая, то есть текущий тред встает в ожидание события доставки с таймаутом.
и опять таймауты вылезают на уровень прикладного программирования, поскольку даже если вы пишете простой текстовый коммуникатор по радиоканалу типа точка-точка, вам придется убеждаться в успехе доставки ваших сообщений в прикладном коде. и этот код должен уметь варьировать таймаут. например его увеличить или уменьшить.

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


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

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

Да всё из этого самого, из Oberon-SA -- прототипа Оберона-07...
Когда, кстати, описание-то виртово появится? Ещё полгода назад объявляли, а до сих пор ни слуху, ни духу... А Вы ещё возмущаетесь, что проныры-американцы отовсюду вытеснили нерасторопную европейскую школу... :о))

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

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

Разве? Мёртвый код в процедурных/функциональных языках может быть легко удалён транслятором, а в ООП-языках? Кто его знает, когда, кто и как будет вызывать виртуальные методы, которые могут быть уточнены лишь во время работы программы? Вот и придётся на всякий случай хранить иерархии бесполезных классов...
Для работы в "в жестких условиях аппартных органичений" это может быть критично...

А вот есть примеры написания операционных систем на функциональных языках типа Хаскелл, SASL, Lisp...
Что Вы думаете по этому поводу? ;о)

Тише едешь - дальше будешь...
Семь раз отмерь...
- как гласит народная мудрость... и пусть себе космические корабли бороздят Большой тяатр

"Общего, даже приблизительного.." в отрыве от задачи быть, конечно, не может. Но для конкретного приложения такой сценарий действий вполне можно выделить и описать отдельно. Согласитесь, общепринятая практика - размазывать код обработки маловероятных исходов по всей логике приложения как-то уж очень громоздко...
Почему бы не позволить прикладнику написать 95% кода "чисто", поверх "надёжных" абстракций, а затем собрать в одном месте, в спец. компоненте всю логику обработки отказов? И этот компонент подключить к библиотеке, сказав: "Если отказ, то сюда ходы...". Идея та же, что в мейнстримовской обработке исключений. Только без тупой раскрутки стека... (а узнать контекст, в котором произошёл отказ, всегда можно с помощью тех же метамеханизмов).

Прекрасная формулировка! Я Мейера не читал, но сам по размышлении сформулировал этот принцип именно так. Исключения должны генерироваться только тогда, когда функция не может обеспечить свой контракт. А единственный случай, когда функция имеет право не обеспечить контракт - если под ней лежит некая ненадёжная среда (ввод-вывод, сеть), а выносить эту ненадёжность для клиентов наверх (через коды ошибок) она не хочет (слишком высокоуровневая). Вот тут-то и требуется обработка исключений.
Только я за то, чтобы не раскручивать стек до ближайшего except-а, а делать спец. ОО-хуки, которые клиент некоторой службы к ней подключает (говоря "если не можешь обеспечить контракт, сигналь мне сюды, а я буду разбираться, что делать далее"). Т.е. обработка исключений обычными ОО-паттернами.

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

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

По поводу ООП - конечно, это не препятствие для ОС.
Но по поводу Си я бы назвал два важных аргумента:
1) Си - компактный язык. С++ - навороченный бронтозавр, а значит - ошибко/проблемо-опасен. Единственный вариант "лечения" - работать на жёстко определённом подмножестве. "Административные меры".
2) Следствие п. 1 - нет ни одного 100%-правильного и/или соотв. стандарту компилятора С++.

И можно привести п.3, касающийся ООП в С++ - и не только в С++, а в немодульных языках вообще.
Инкапсуляция и сокрытие информации в них возложено на классы (т.е. модульность эмулируется классами).
Для системного программирования характерны группы мелких классов, тесно взаимодействующих друг с другом. Таким образом, нужно либо чрезмерно открывать интерфейсы, либо терять эффективность, либо хитрить с несколькими интерфейсами (.h-файлами, для "своих" и "чужих") да использовать "костыли" типа friend.
В модульных языках проблема решается изящно - инкапсуляция возложена на модули. Группа типов ("классов"), объявленных в одном модуле, имеет полный доступ к полям друг друга. Так называемое no paranoia rule. Что и требуется для системного программирования.

Как сказал Фоменко -- пока семь раз отмеришь, другие уже отрежут.
Что мы и наблюдаем повсеместно... :о))

Да всё идёт путём... Критерий своевременности - это успевание решать реальные поступающие задачи, а не скорость генерации/комбинирования тулзов и фич

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

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

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


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

Почему? Любой прикладной актёр является клиентом системного. В сложных системах имеют право быть обратные связи от службы к клиенту. Системный актёр обрабатывает запрос от прикладного, даёт на него, так скажем, callback - и оказывается в зависимости от его низкого приоритета.
Почему бы не привязать понятие приоритета к сообщениям, а не к актёрам?

На почте ведь нет низкоприоритетных и высокоприоритетных узлов. Каждый узел в первую очередь обрабатывает проходящие сообщения с наивысшим приоритетом.

Нет, не нужно максимализма. Опять же, нужно принимать как можно менее связывающие технические решения.
Если в модели распределёнки обработка ведётся через подключаемые обработчики, то прикладник всегда может использовать такую детализацию, какая ему нужна. Общий обработчик на несколько модулей, по обработчику в каждом, спец. обработчики для некоторых отдельных функций.
А всегда перекладывая обработку на вызывающего клиента, Вы обязуете прикладника использовать один и только один, наиболее мелкий уровень детализации. То есть, только "размазывать" - и никак иначе.

te]В сложных системах имеют право быть обратные связи от службы к клиенту. [/quote]
обратные связи быть могут. но оформляются они специальным образом.
если сервер обслуживает N клиентов, он заводит N тредов обслуживания, и общается с каждым из клиентов отдельно в индивидуальном треде. такой тред не является критическим тредом для работы всей службы, и его блокировка службе жизнь не портит. критические треды службы клиенты видеть не могут. я об этом и говорю. если тред обслуживания заблокируется клиентом, то за счет таймаута, он выскочит из блокировки, и сообщит самой службе, что клиент умер, отвис, не отвечает, и служба решит скорее всего тред замочить, канал закрыть и записать что-то в лог. и усе.


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

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

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

Кроме того, использование блокирования без возможности раблокировки по условию (например - таймауту, аки в QNX) - не то, что "нонсенс", а просто - в высшей степени - моветон-с...

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