OberonCore

возможно не очень понял вопрос, поскольку в обероне и его клонах новичок. Но.

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

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

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

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

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

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

Всё, что Вы описали, это, бесспорно, верно. Однако это "ассемблер" параллелизма. Все его знают, но нельзя же вечно писать на ассемблере
Вот про то и думки, какие абстракции над этим "ассемблером" надстраивать.

Кстати, чтобы предварить ненужные дискуссии: если Вы сомневаетесь в возможности "высокоуровневого параллелизма", то посмотрите как на пример, на язык реального времени Аду и на её абстракции параллельности, которые очень далеки от мьютексов, семафоров и тредов. (http://ada-ru.org/V-0.4w/toc_ru.html, гл. 15).

Кстати, я недавно баловался с потоками (лёгкие потоки Хаскелла) и процессами ОС в кубунте, и не смог запустить одновременно больше 360 процессов ОС, хотя в винде запускал 1003 (WinXP) / 1004 (Win2003) процесса... И виндовый экзешник из-под wine вапще больше 160 процессов создавать не захотел...
Как так? Что я делал не так? В Линуксе вапще есть какие-то способы указания, сколько процессов может максимально на программу приходиться?

Ну, посмотрите мою презентацию с последнего семинара в МАИ, там я эту тему затрагивал... (http://metasystems.ru/science.php?page=pub).
"Не рассказал толком", потому что всё это только поиски, гипотезы...

Не знаю, я многопоточность в Линуксе ещё глубоко не копал...
Скажу точно одно, что на много потоков мейнстрим-ОСы просто не расчитаны.
Поэтому перспективным таки кажется подход с введением легковесных потоков.
Посмотрите в ветке по Оберону на Королевстве Дельфи недавнюю нашу беседу с участником с ником "Стэн". У него сделана библиотека актёров на легковесных потоках. (В общем-то, ноги у всего этого растут от Эрланга.) У него очень толковый подход, я его "намотал на ус".

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

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

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

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

плохая аналогия.

безукоризненная многопоточность должна писаться так
на псевдокоде
IF some_mutex.lock(1000(*ms*)) DO
..................
ELSE
Error("cannot lock critical mutex during 1000ms!!! - some trouble guys!");
END;

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

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

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

Я бы не назвал его "концептуальным". Т.к. та же логика может быть и без него запрограммирована.
Но я не спорю против того, что иметь возможность простого контроля таймаута может быть полезно.

Однако в том же Active Oberon её нет, и что? Операционная система на нём написана целиком - и отлично работает.

Посмотрите презентацию - там вкратце обрисованы контуры той модели, которую планируем делать (асинхронные типизированные сообщения, с неявными "тредами", т.е. light-weight). Так вот, там можно поддержать транзакционность для объектов (т.е. откат последствий посланного сообщения в случае, например, блокировки).
Интересная работа на тему разделения доступа к сложным динамическим структурам - Wolfgang Weck "Immutable data structures in Component Pascal" (типа того) - есть на EuroProg. Про то, как реализовать на КП структуры данных с принципов "копирование при изменении" (как в ФП) и гарантировать языковыми средствами соблюдение правил работы с ними.

где сия презентация?

Да я выше ссылку давал:
http://metasystems.ru/science.php?page=pub

Правда, она весьма общая и подразумевает, что человек "в теме" (в первую очередь знаком с обероновской Generic Message Bus).

Подтверждаю!
Там "ограниченность ожидания" просто явно вынесена в возможность зппуска таймера и описывания следующего условия ожидания:
Или - ещё так делают: создают логическую переменную в объекте где нужно ожидание по таймауту. А таймеру передают ссылку на один из методов, где просто этой переменной устанавливается логическая истина ("было срабатывание")Какие проблемы? Всё - "по Вирту" - все действия ( вся логика ) явно описаны и наблюдаемы

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

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