OberonCore :: - Проблемы параллельного пр-я и пути их решения

больше ничего особо мудрого там нет.

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

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

Вот Вы так и не рассказали толком, чем же Вас активные объекты в конце концов не устроили... :cry:

Как так? Что я делал не так? В Линуксе вапще есть какие-то способы указания, сколько процессов может максимально на программу приходиться?

нельзя же вечно писать на ассемблере

Вот про то и думки, какие абстракции над этим "ассемблером" надстраивать.

Все его знают, но нельзя же вечно писать на ассемблере

то посмотрите как на пример, на язык реального времени Аду и на её абстракции параллельности, которые очень далеки от мьютексов, семафоров и тредов.

Цитата:

Все его знают, но нельзя же вечно писать на ассемблере

причем тут ассемблер???

Это аналогия-эпитет: ассемблер параллелизма, ассемблер ООП...

безукоризненная многопоточность должна писаться так
на псевдокоде

IF some_mutex.lock(1000(*ms*)) DO
..................
ELSE
Error("cannot lock critical mutex during 1000ms!!! - some trouble guys!");
END;

а таймаута нет.

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

А что Вы думаете о таких технологиях, как параллелизм уровня данных (Nested Data Parallelism) и транзакционная память (Software/Hardware Transactional Memory)? Они сейчас вроде бы сильно популярными становятся, особенно учитывая всё большее распространение многоядерных процессоров...

Посмотрите презентацию

Но я не спорю против того, что иметь возможность простого контроля таймаута может быть полезно.
Однако в том же Active Oberon её нет, и что? Операционная система на нём написана целиком - и отлично работает.

Там "ограниченность ожидания" просто явно вынесена в возможность зппуска таймера и описывания следующего условия ожидания:

Какие проблемы? Всё - "по Вирту" - все действия ( вся логика ) явно описаны и наблюдаемы

Автор:	merk [ Вторник, 01 Январь, 2008 17:19 ]
Заголовок сообщения:	Проблемы параллельного пр-я и пути их решения
возможно не очень понял вопрос, поскольку в обероне и его клонах новичок. Но. ситуация похожа на такую. для правильной реализации многопоточности и работы с эсклюзивно захватываемыми(залоченными) обьектами необходима функции 1. захвата - освобождения обьектов...ну типа lock, unlock. 2. дополнительная функция ожидания внутри участка, куда вошел тред монопольно. в самом прямом смысле эта необходимость возникает для эффективной реализации самой обычной очереди, в которую произвольное количество тредов могут класть обьекты и произвольное - извлекать. тогда функция взять обьект из очереди корректно реализуется так. 1. тред старается захватить мьютекс очереди с нужным таймаутом. если мьютекс захвачен, тред работает с очередью монопольно и может ее модифицировать(например извлечь из списка очереди событие с его верхушки). Но если очередь пуста тред должен мьютекс освободить и встать в ожидание некоего сигнала - "кто-то положил в очередь обьект". можно тупо конечно выйти, уснуть и снова попытаться захватить мьютекс и проверять непустоту очереди. но это дейстивтельно тупо, поскольку исключительно неверно для event-driven модели. за такую реализацию очереди в приличных коллективах следует убивать. единственным средством реализации нужной функциональности является некий обьект синхронизации на который можно вставать треду с разлочиванием залокнутого им мьютекса. причем это делается атомарно и операция - разлочивание мьютекса и вставание в ожидание сигнала(события) не могут прерываться другим тредом. если такой функциональности нет, ее невозможно смоделировать остальными средствами синхронизации. кто не верит, может посмотреть как в ваших многопоточных системах реализована базовая очередь. она должна быть реализована именно с этими фичами. итак есть две принципиально разные функциональности как минимум 1. обеспечение монопольной работы треда с пассивным обьектом - это лок, анлок мьютекса обьекта. 2. передача синхронизирующих сигналов между тредами, ну например ожидания тредов на обьектах типа флаг, сигнал и проч. лабуда. из пересечния этих двух функциональностей возникает необходимость использовать сигналирование(п2) внутри залоченных участков(п1). то есть, как раз, атомарная операция - анлок участка и вставание на сигнал. кстати это единственное, часто непонятное для несталкивающихся, место в кухне синхронизации тредов. больше ничего особо мудрого там нет.

Автор:	Илья Ермаков [ Вторник, 01 Январь, 2008 18:21 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
merk писал(а): больше ничего особо мудрого там нет. В реализации абстракций типа монитора ничего особо мудрого, и правда, нет. А вот глобально я бы так не сказал Для начала найти бы, наконец, идеальный набор абстракций для параллелизма, для более-менее универсального спектра задач... Мониторы/активные объекты, кажись, такую роль не тянут.

Автор:	Geniepro [ Вторник, 01 Январь, 2008 18:35 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Илья Ермаков писал(а): Для начала найти бы, наконец, идеальный набор абстракций для параллелизма, для более-менее универсального спектра задач... Мониторы/активные объекты, кажись, такую роль не тянут. Вот Вы так и не рассказали толком, чем же Вас активные объекты в конце концов не устроили...

Автор:	Илья Ермаков [ Вторник, 01 Январь, 2008 18:39 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
merk писал(а): ситуация похожа на такую. для правильной реализации многопоточности и работы с эсклюзивно захватываемыми(залоченными) обьектами необходима функции 1. захвата - освобождения обьектов...ну типа lock, unlock. 2. дополнительная функция ожидания внутри участка, куда вошел тред монопольно. в самом прямом смысле эта необходимость возникает для эффективной реализации самой обычной очереди, в которую произвольное количество тредов могут класть обьекты и произвольное - извлекать. тогда функция взять обьект из очереди корректно реализуется так. Всё, что Вы описали, это, бесспорно, верно. Однако это "ассемблер" параллелизма. Все его знают, но нельзя же вечно писать на ассемблере Вот про то и думки, какие абстракции над этим "ассемблером" надстраивать. Кстати, чтобы предварить ненужные дискуссии: если Вы сомневаетесь в возможности "высокоуровневого параллелизма", то посмотрите как на пример, на язык реального времени Аду и на её абстракции параллельности, которые очень далеки от мьютексов, семафоров и тредов. (http://ada-ru.org/V-0.4w/toc_ru.html, гл. 15).

Автор:	Geniepro [ Вторник, 01 Январь, 2008 18:41 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Кстати, я недавно баловался с потоками (лёгкие потоки Хаскелла) и процессами ОС в кубунте, и не смог запустить одновременно больше 360 процессов ОС, хотя в винде запускал 1003 (WinXP) / 1004 (Win2003) процесса... И виндовый экзешник из-под wine вапще больше 160 процессов создавать не захотел... Как так? Что я делал не так? В Линуксе вапще есть какие-то способы указания, сколько процессов может максимально на программу приходиться?

OberonCore https://forum.oberoncore.ru/

Проблемы параллельного пр-я и пути их решения https://forum.oberoncore.ru/viewtopic.php?f=31&t=807	Страница 1 из 3

Автор:	merk [ Вторник, 01 Январь, 2008 19:07 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Цитата: Все его знают, но нельзя же вечно писать на ассемблере причем тут ассемблер??? все ваши синхронные функции или как оно там,..просто лочат встроенный мьютекс. в ядре примитивы вроде мьютекса, сигнала, треда, будут по любому. их просто можно пользовать явно, а можно генерировать код использования прямо из компилятора. и будет типо продвинуто и крута... а таймаута нет. это трындец между прочим, как бы высокоуровнево ни программировали. трындец концептульальный.

Автор:	merk [ Вторник, 01 Январь, 2008 19:11 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Цитата: то посмотрите как на пример, на язык реального времени Аду и на её абстракции параллельности, которые очень далеки от мьютексов, семафоров и тредов. все концепции паралельности похожи по сути. детали лишь в том, кто что считает единицей кода исполняемого в отдельном потоке, и как обзывает те или иные механизмы синхронизации этих единиц кода.

Автор:	Борис Рюмшин [ Вторник, 01 Январь, 2008 19:15 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
merk писал(а): Цитата: Все его знают, но нельзя же вечно писать на ассемблере причем тут ассемблер??? Это аналогия-эпитет: ассемблер параллелизма, ассемблер ООП...

Автор:	merk [ Вторник, 01 Январь, 2008 19:21 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Цитата: Это аналогия-эпитет: ассемблер параллелизма, ассемблер ООП... плохая аналогия. безукоризненная многопоточность должна писаться так на псевдокоде IF some_mutex.lock(1000(ms)) DO .................. ELSE Error("cannot lock critical mutex during 1000ms!!! - some trouble guys!"); END; тогда оно работать будет и не нужно супервизора, что предлагается, для сталкивания застрявших тредов. Нужно помнить, что на одном мьютексе могут тусоваться треды разных авторов...и даже разных национальностей, разных религиозных конфессий, и потому, если мой тред написан безукоризненно, почему его должен грохать какой-то супервизор, если это не моя вина? а? если в обероноподобных языках так можно записать - тогда все ок - если нет - расширяйте синтаксис.

Автор:	merk [ Вторник, 01 Январь, 2008 21:09 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Цитата: Посмотрите презентацию где сия презентация?

Автор:	Wlad [ Вторник, 01 Январь, 2008 23:29 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Илья Ермаков писал(а): Но я не спорю против того, что иметь возможность простого контроля таймаута может быть полезно. Однако в том же Active Oberon её нет, и что? Операционная система на нём написана целиком - и отлично работает. Подтверждаю! Там "ограниченность ожидания" просто явно вынесена в возможность зппуска таймера и описывания следующего условия ожидания: Код: ... timer.Start( ourWaitConstrTimeInMS ); AWAIT( myCondition OR timer.Expired ); IF timer.Expired THEN Делаем что-то по тайм-ауту ELSE timer.Stop(); делаем что-то "штатное" END ... Или - ещё так делают: создают логическую переменную в объекте где нужно ожидание по таймауту. А таймеру передают ссылку на один из методов, где просто этой переменной устанавливается логическая истина ("было срабатывание") Код: ... timeExpired : BOOLEAN; PROCEDURE SetTimeOut; BEGIN timeExpired := TRUE; END SetTimeOut; ... timeExpired := FALSE; timer.Start( SetTimeOut ); AWAIT( myCondition OR timeExpired ); IF timeExpired THEN Делаем что-то по тайм-ауту ELSE timer.Stop(); делаем что-то "штатное" END ... Какие проблемы? Всё - "по Вирту" - все действия ( вся логика ) явно описаны и наблюдаемы

Автор:	merk [ Среда, 02 Январь, 2008 01:14 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Цитата: Там "ограниченность ожидания" просто явно вынесена в возможность зппуска таймера и описывания следующего условия ожидания: вот видите, зубры из цюриха, не такие уж и дети...но! уж больно это все косоруко. это даже хуже чем ассемблер из мьютексов, в котором меня немного упрекнули. в нормальной системе вся эта таймерная кухня просто скрыта в реализации синхрообьектов. более того. такой синхрообьект просто описывается одним базовым классом. и все классы, конкретных синхрообьектов, что требуют ожидания, наследуют от базового. а тут, в данной записи, вся требуха вывертывается наружу.

Автор:	merk [ Среда, 02 Январь, 2008 01:17 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Цитата: Какие проблемы? Всё - "по Вирту" - все действия ( вся логика ) явно описаны и наблюдаемы нуу это не по вирту. по вашему "вирту" ваще пришлось бы на ассемблере писать. абсолютно избыточная возня с таймерами на уровне прикладного кода.

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

Автор:	Илья Ермаков [ Вторник, 01 Январь, 2008 18:48 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Geniepro писал(а): Как так? Что я делал не так? В Линуксе вапще есть какие-то способы указания, сколько процессов может максимально на программу приходиться? Не знаю, я многопоточность в Линуксе ещё глубоко не копал... Скажу точно одно, что на много потоков мейнстрим-ОСы просто не расчитаны. Поэтому перспективным таки кажется подход с введением легковесных потоков. Посмотрите в ветке по Оберону на Королевстве Дельфи недавнюю нашу беседу с участником с ником "Стэн". У него сделана библиотека актёров на легковесных потоках. (В общем-то, ноги у всего этого растут от Эрланга.) У него очень толковый подход, я его "намотал на ус".

Автор:	Илья Ермаков [ Вторник, 01 Январь, 2008 20:03 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Geniepro писал(а): А что Вы думаете о таких технологиях, как параллелизм уровня данных (Nested Data Parallelism) и транзакционная память (Software/Hardware Transactional Memory)? Они сейчас вроде бы сильно популярными становятся, особенно учитывая всё большее распространение многоядерных процессоров... Посмотрите презентацию - там вкратце обрисованы контуры той модели, которую планируем делать (асинхронные типизированные сообщения, с неявными "тредами", т.е. light-weight). Так вот, там можно поддержать транзакционность для объектов (т.е. откат последствий посланного сообщения в случае, например, блокировки). Интересная работа на тему разделения доступа к сложным динамическим структурам - Wolfgang Weck "Immutable data structures in Component Pascal" (типа того) - есть на EuroProg. Про то, как реализовать на КП структуры данных с принципов "копирование при изменении" (как в ФП) и гарантировать языковыми средствами соблюдение правил работы с ними.

Автор:	Илья Ермаков [ Вторник, 01 Январь, 2008 21:12 ]
Заголовок сообщения:	Re: EXCLUSIVE и AWAIT
Да я выше ссылку давал: http://metasystems.ru/science.php?page=pub Правда, она весьма общая и подразумевает, что человек "в теме" (в первую очередь знаком с обероновской Generic Message Bus).