OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 11:11

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




Начать новую тему Ответить на тему  [ Сообщений: 26 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: Параллелизм
СообщениеДобавлено: Понедельник, 21 Октябрь, 2013 14:03 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Madzi писал(а):
Для реал-тайм и хард-реал-тайм задач сборщик мусора использовать запрещено. Т.е. если объект имеет директиву
Код:
{realtime}
, то модуль не скомпилируется если у объекта есть выделение/удаление динамической памяти.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Параллелизм
СообщениеДобавлено: Понедельник, 21 Октябрь, 2013 14:40 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Kemet безусловно прав. А "переключения контекстов" не происходит в другом смысле: между кольцами защиты. Все потоки работают на одном уровне защиты, а разграничение как раз и обеспечивается языком.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Параллелизм
СообщениеДобавлено: Понедельник, 21 Октябрь, 2013 15:05 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
То есть, у каждого объекта свой стек?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Параллелизм
СообщениеДобавлено: Понедельник, 21 Октябрь, 2013 15:10 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Александр Ильин писал(а):
То есть, у каждого объекта свой стек?
У каждого Активного Объекта - да.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Параллелизм
СообщениеДобавлено: Пятница, 21 Февраль, 2014 18:50 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Rifat писал(а):
...
Меня заинтересовала фраза "объектно-ориентированный подход предлагает более эффективный способ хорошего использования параллелизма, когда поведение каждого объекта представляется в виде отдельного процесса" и у меня есть несколько вопросов:
1) реализован ли данный подход где-нибудь?
2) если да, то позволяет ли данный подход формально доказывать корректность программ?
3) если не позволяет, то есть ли другие методы параллелизма, которые можно реализовать и при этом формально доказывать корректность таких программ.


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

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

В коде это выглядит так, что обработчик сообщения понятия не имеет, кто прислал ему это сообщение. И, главное, когда. В асинхронных системах появляется категория времени, которая формализуется не знаю кем. Узнать бы. Это даст ключ к формальному доказательству правильности асинхронных программ.

Потенциал определения отправителя сообщений зависит от реализации платформы, а вот некая временная недетерминированность, действительно, имеет неслабый эффект. Вот неплохой пример: Analyzing Singularity Channel Contracts. В публикации речь идёт о косяках разработчиков Singularity, допустивших возможные взаимоблокировки при общении изолированных процессов по средствам каналов, а потенциал блокировок определен через:
Илья Ермаков писал(а):
Если использовать взаимодействия на сообщениях изолированных процессов, то один из методов доказательства корректности - построение модели на какой-нибудь Promela и далее автоматизированный Model-Checking.

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

Некоторую критику модели процессов на сообщениях даёт основатель Кложуры Rich Hickey, например, здесь пару слов: Identity and State. Кроме того, что сложно организовать корректную работу массы агентов, общающихся между собой только через "почту", но и не всё так однозначно идентично налаживаются процессы внутри приложения и внешне взаимодействующие (к примеру, по сети). Предлагаемая им модель многопоточности на базе STM (software transactional memory, Concurrent Programming) несколько сглаживает шероховатости ориентировки процессов во времени (в т.ч. имеются идентичные модели и для распределенного взаимодействия -- Avout). Основной недостаток технологий поверх STM -- потенциал для эффективной реализации (по производительности, памяти и др.)

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

Ещё одна популярная "высоко детерминированная" модель -- парадигма "fork-join". Здесь в начале презентации пример реализации на java (там речь идёт о библиотеке Reducers кложуры, которая использует fork-join), здесь представлены ключевые особенности этой реализации, где главное -- попытка эффективного автоматического распределения нагрузки процессоров/ядер.

Но, многие мэйнстрим-строители платформ забывают, что кроме "автомата" необходимо и ручное управление нагрузкой (а не только то, что таинственным образом вытворяют, к примеру, "параллельные" коллекции, сами решая, как жечь процессоры). Причём простое управление, например, как в языке Julia, где исполняемая процедура/функция привязывается к процессору/ядру простым указанием необязательного передаваемого параметра. И, кстати, сама модель параллельности напоминает типовые "Futures" или "Promises" -- запускается параллельная функция и позже читаются её результаты. В какой-то степени, можно сказать, что Futures/Promises -- концептуально напоминают части или этапы модели fork-join. А модель Disruptor-a, в свою очередь, выглядит как "fork-join в цикле" (условно, т.к. в "производственном конвейере" могут быть несколько производителей сообщений, могут не быть конечных "join"-ов). Вот и проглядывается относительно однородный комлектик моделей как альтернатива агентам, особенно учитывая, что в стиле Futures/Promises организуется распределенное общение программных элементов. При этом, эта связка "по детерминированности" очень близка к однопоточному коду (например, фактически, не требует временных диаграмм), и покрывает широкие потребности.

Таким образом, насчёт моделей агентов/акторов -- не всё так однозначно просто как "более эффективный способ хорошего использования параллелизма". Причём не только с позиции "лёгкости" организации именно корректной асинхронной работы агентов, но и при взгляде на потенциал технической реализации. Также не стоит забывать о важности прямого управления нагрузкой процессоров (кроме автоматического и именно "интеллектуального", и лучше в сотрудничестве с ним), и даже "легковесные", "зеленые" потоки не могут соперничать с полноценной прямой грамотной загрузкой физического ядра процессора без никаких переключений приложением на другие потоки (а модель акторов, в целом, как единое обширное приложение, требует каких-то распределенных переключений потоков, чтобы выравнивать среднюю температуру по больнице. И многие пытающиеся применять зеленые потоки, наслышавшись об успехах Erlang-a, ещё забывают о том, что его потоки, прежде всего, реализуют т.н. "soft realtime" -- ограничивают верхний предел кванта времени для исполняемых инструкций своей виртуальной машины).
Отсюда, не всё так просто и с утверждением:
Н. Вирт писал(а):
...Вообще-то относительно несложно определить, какие части выражения могут вычисляться параллельно. Более важно то, что параллельно могут вычисляться параметры вызываемой функции, если запрещены побочные эффекты - которые не могут возникать в истинно функциональном языке...

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

И ещё одно замечание. Не всегда параллельность оправдывает себя, когда, по факту, не требуются как таковых параллельных действий. В языке Felix (скриптовый язык, дающий на выходе код на С++) есть полезная концепция -- Fibres -- агенты на основе однопоточной кооперативной модели, причём даются некоторые полезные прикладные техники (фактически, здесь агенты -- для задач динамической конфигурации приложений, когда заранее не известно, какой объект с кем будет общаться).

Все модели выше (включая и агентов) не зависят от "объектности", "функциональщины" или "процедурности". Причём это модели "высокого уровня", для организации работы "почтовых ящиков" и иных механизмов нужны "низкоуровневые модели", или прикладные модели могут быть реализованы непосредственно поверх базового уровня. Рекомендую: "Эндрюс Г.Р. Основы многопоточного, параллельного и распределенного программирования", где затронуты многие распространенные технологии (правда не все современные тенденции отражены, включая особенности процессоров, развитие алгоритмов без блокировок и др.).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Параллелизм
СообщениеДобавлено: Пятница, 21 Февраль, 2014 20:54 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Между процессами еще накладнее сообщения передавать.
А что делать, ведь другого пути нет.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 26 ]  На страницу Пред.  1, 2

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


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

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9


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

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