OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 14 Декабрь, 2017 13:00

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




Начать новую тему Ответить на тему  [ Сообщений: 27 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: Про гранулярность у coroutines
СообщениеДобавлено: Понедельник, 09 Октябрь, 2017 10:32 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 620
Откуда: Казань
Илья Ермаков писал(а):
Речь-то о том, что из всех видов параллелизма сопрограммы позволяют контролировать ситуацию лучше всего (требуя совсем немного доп. анализа от программиста по сравнению с последовательным программированием).

Данное утверждение про "лучше всего" мягко говоря не доказано.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про гранулярность у coroutines
СообщениеДобавлено: Понедельник, 09 Октябрь, 2017 10:54 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 199
Откуда: Москва
Рифат писал(а):
она прерывается и запускается вторая сопрограмма, которая сбрасывает c.found в FALSE

Нет, у каждого экземпляра объекта своя структура данных. Соответственно, c1.found и c2.cound. И решение нужно принимать по c1.found OR c2.found

Угроза - глобальные переменные, сопрограммы тут не при чем.
Не используйте одну глобальную переменную для двух переменных (хоть found, хоть c.found).
Вложение:
alarmGlob.png
alarmGlob.png [ 5 КБ | Просмотров: 200 ]


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про гранулярность у coroutines
СообщениеДобавлено: Понедельник, 09 Октябрь, 2017 10:58 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 620
Откуда: Казань
Значит вся логическая нагрузка ляжет на функцию, которая должна анализировать результаты c1.found и c2.found.
Все равно остается 9 разных вариантов, которые нужно учитывать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про гранулярность у coroutines
СообщениеДобавлено: Понедельник, 09 Октябрь, 2017 20:25 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
prospero78 писал(а):
И всё-таки верификация не решает проблем системы и сети. Это ооочень накладно. Где-то видел шуточный селфтест: он проверял правильность того, что процедура принимала два числа и всегда возвращала ноль. Исполнение -- идеальное. Смысл? Верификация верифицировала процедуру на то, что та работает верно, результат смысла не имеет.
Опять же, как верифицировать результат при квантовых вычислениях? Это точно возможно?
Считаю подход Вирта -- строить программы в оборонительном стиле -- достаточным вместе с контрактным программированием.
Многопоточность и многопроцессность -- особенно последнее -- требует усилий. Что-то, конечно можно сделать. Даже наверное нужно (раз Дмитрий сделал).
Но важно вовремя остановиться. Чем изощрённей методика -- тем больше вероятность ошибки. А нет ничего дороже на этом свете чем глупость.

Некоторые уточнения по поводу:
viewtopic.php?f=152&t=6049&p=102293#p102292


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про гранулярность у coroutines
СообщениеДобавлено: Понедельник, 09 Октябрь, 2017 20:29 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
Rifat писал(а):
Основной вывод: нельзя взять обычную однопоточную программу, добавить туда Co.Yield(); и ожидать, что программа останется корректной.

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

Да, и, всё-таки, "конкурентные" процессы первично подразумеваются "однопоточными", с детерминированной политикой работы. По ходу дела, пример синтеза систем (мат. постановки) с учётом глобальных объектов и сохранения семантики в случае "переезда" планировщика на "вытесняющую" (условно недетерминированную) модель:
From non-preemptive to preemptive scheduling using synchronization synthesis

Это в рамках проекта Termite:
http://ssrg.nicta.com.au/projects/TS/drivers/synthesis/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про гранулярность у coroutines
СообщениеДобавлено: Вторник, 10 Октябрь, 2017 16:35 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8902
Откуда: Россия, Орёл
Задачи должны взаимодействовать с небольшой частью глобального состояния.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про гранулярность у coroutines
СообщениеДобавлено: Вторник, 10 Октябрь, 2017 19:08 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 191
Более того, для конкурентного (кооперативного) взаимодействия существует возможность выявлять deadlock в кооперации. Пример реализации (язык Felix -- скриптовый в стиле ML для генерации кода на С++):
http://felix-lang.org/share/src/web/tut ... index.fdoc

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

А задача монитора в общем случае универсальна. Ниже статья с примером неплохой технологии:
Вложение:
Parallel object monitors.pdf [5.91 МБ]
Скачиваний: 4

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


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

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


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

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


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

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