OberonCore
https://forum.oberoncore.ru/

Механизм агрегации деталей
https://forum.oberoncore.ru/viewtopic.php?f=47&t=4175
Страница 1 из 1

Автор:  Пётр Кушнир [ Пятница, 30 Ноябрь, 2012 19:26 ]
Заголовок сообщения:  Механизм агрегации деталей

Третьего дня наткнулся на статью про механизм деталей из сборки Актив ББ (pdf-копию прикрепил для ознакомления).
Пришла в голову идея, реализовать подобное в виде библиотеки на стоковом ядре. Ну а тут и задача подвернулась, надо было доставить невидимому отображению на фоновой вкладке StdTabViews сообщение. Понятное дело, механизмами ББ не удалось доставить сообщение отображению без фрейма.
Поэтому склепал реализацию механизма деталей (ну или то, как я его понял), прицепил к отображению детальку, которая подключается к межмодульной шине и доставляет сообщения объекту. И всё. Всё заработало, с отдельными недостатками, но, у меня не возникло других идей применения деталей, кроме как прикрепить хендлер шины.

В связи с этим вопрос, видимо к И. Ермакову: а для чего ещё планировалось применять механизм деталей, и почему, в итоге, он остался похороненным в АББ, а не вынесен в отдельную библиотеку (не очень сложную, как мне показалось)?

Вложения:
details-abb.pdf [124.02 КБ]
Скачиваний: 544

Автор:  Иван Кузьмицкий [ Пятница, 30 Ноябрь, 2012 21:13 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

Присоединяюсь к вопросу и дополнительно интересны причины фунерализации Active BlackBox :) Активные объекты чудо как хороши, пробовали - знаем )

Автор:  Илья Ермаков [ Воскресенье, 02 Декабрь, 2012 00:51 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

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

По поводу активных объектов - я считаю более эффективным подходом и применяю легковесный параллелизм в рамках одного (или нескольких по числу ядер) потоков. Без необходимости взаимного исключения... Собственно, опыт очень шустрых систем типа Node.Js или некоторых noSQL (mail.ru tarantool, например) меня в этом только убеждает. Да даже тот же Erlang!

Автор:  Иван Кузьмицкий [ Воскресенье, 02 Декабрь, 2012 01:09 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

Илья, нельзя ли про легковесный параллелизм немножко поподробнее рассказать?

Автор:  Владислав Жаринов [ Воскресенье, 02 Декабрь, 2012 09:00 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

Да, немножко подробнее, чем в Википедии :), было бы интересно...

Автор:  Иван Кузьмицкий [ Воскресенье, 02 Декабрь, 2012 15:45 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

Владислав Жаринов писал(а):
Да, немножко подробнее, чем в Википедии :), было бы интересно...
Я же не просто так спрашиваю. Мне неинтересны бесконечные теоретические рассуждения, потому что у меня есть основной инструмент - BlackBox и как раз в применении к нему параллелизм и интересен.

Автор:  Владислав Жаринов [ Воскресенье, 02 Декабрь, 2012 15:57 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

Да мне тоже - что делается и какими языковыми средствами...

Автор:  Илья Ермаков [ Воскресенье, 02 Декабрь, 2012 18:57 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

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

Для задач, где сложный "поток логики" и не хотелось бы прерываться, можно использовать нечто типа fiber-ов: в определённых местах процедуры ставится вызов типа Dispatcher.Switch, при котором диспетчер даёт поработать другой процедуре (всё в одном потоке).
Взаимное исключение на уровне защиты целостности уже становится не нужным.
Кстати, в Composita швейцарцы сделали именно такой параллелизм, но вызовы Switch вшивает в код компилятор (насколько я вкуривал их документацию).
А теперь поделим лёгкие задачи (так, чтобы они практически не пересекались по общим данным) между потоками по числу ядер. Тут уже взаимное исключение, конечно, понадобится, на взаимодействиях между несколькими "областями". Но появляется возможность синхронизации, которой нет при обычных потоках. Например, сборщику надо остановить всю активность в системе. При обычных потоках вы не можете их остановить просто так - хрен знает, где он был застукан.... Для отладочных целей проверяют регистр IP потока - и если он в неприличном месте, то поток снова резюмят, а потом опять суспендят, пока он не будет где-нибудь в подходящем месте... Но это только для отладки.
Так вот, при легковесном параллелизме, когда у вас все активности переключаются через Switch, то вы можете легко сделать GlobalLock в моменты, когда они вызовут Switch.
Ну а от зависаний защита - поток-watchdog, который генерирует исключение в том потоке, который слишком долго не вызывал Switch...

Автор:  Владислав Жаринов [ Понедельник, 03 Декабрь, 2012 08:28 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

Это не похоже на механизмы (не язык, :) а именно принцип реализации), обсуждавшиеся здесь: viewtopic.php?p=43805#p43805 ?..

Автор:  Иван Кузьмицкий [ Понедельник, 03 Декабрь, 2012 13:51 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

"Это не те дроиды, которых вы ищете" (с) Кеноби О-В.

Автор:  Владислав Жаринов [ Среда, 05 Декабрь, 2012 13:33 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

Не, наверное, по ссылке не те... :)

Автор:  Пётр Кушнир [ Среда, 05 Декабрь, 2012 13:54 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

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

Автор:  Илья Ермаков [ Среда, 05 Декабрь, 2012 16:55 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

С сообщениями тоже легко проверять. Заводить парное сообщение CheckSupportOf..Msg.

Автор:  Владислав Жаринов [ Вторник, 11 Декабрь, 2012 04:32 ]
Заголовок сообщения:  Re: Механизм агрегации деталей

Кстати, имел в виду, что бурно обсуждавшееся в связи с "синхронизаторами" как-то похоже на сопрограммы, как они описаны здесь: download/file.php?id=1413. И сказанное Ильёй тоже... Может, и Вы, Пётр, подразумевали пример на сообщения также из этого ряда?..

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/