Ответ на »сообщение 1235« (Сергей Губанов)
___________________________

Ответ на »сообщение 1230« (Илья Ермаков)
Каждое обращение к объекту ядра требует порядка 1000 операций

Ответ на »сообщение 1226« (Илья Ермаков)
А вот семафоры для синхронизации и AWAIT реализованы быстрые, пользовательского режима, работают в 12 раз быстрее системных.

М-м-м, я правильно понял, что вход + выход в такой семафор требует примерно 1000/12 = 83 машинных инструкций? В .Net 2.0 вход + выход в System.Threading.Monitor (он же просто lock в C#) требует примерно 5 машинных инструкций. В том случае, разумеется, если он не занят другим потоком.
Если интересно, посчитал точно - 91 инструкция в процедуре Semaphor.WAIT, 68 инструкций - в Semaphore.POST, хотя, естественно, в идеальном случае, когда не нужно ждать, а просто забрать единицу со счетчика, на WAIT пройдет около 20 инструкций.
Блокировка монитора в .NET - это все равно, что простой вход в критическую секцию Win32, там тоже около 5-6 инструкций...

Ответ на »сообщение 1230« (Илья Ермаков)
Каждое обращение к объекту ядра требует порядка 1000 операций

Ответ на »сообщение 1226« (Илья Ермаков)
А вот семафоры для синхронизации и AWAIT реализованы быстрые, пользовательского режима, работают в 12 раз быстрее системных.

М-м-м, я правильно понял, что вход + выход в такой семафор требует примерно 1000/12 = 83 машинных инструкций? В .Net 2.0 вход + выход в System.Threading.Monitor (он же просто lock в C#) требует примерно 5 машинных инструкций. В том случае, разумеется, если он не занят другим потоком.

Ответ на »сообщение 1232« (Сергей Губанов)
___________________________
Критические секции не подходят по той причине, что освобождение критической секции должен выполнять тот же поток, что ее блокировал, сигнал "снаружи" подать на секцию невозможно, это не мьютекс и не семафор. На критических секциях требуется цикл ожидания со Sleep(0), что впустую кушает процессорное время.

В моей реализации поток на семафоре уходит в "бесконечное" ожидание Sleep(INFINITE), а пробуждается, когда в его асинхронную очередь ставится на исполнение процедура-пустышка - WinApi.QueueAPC. Эта пара процедур выполняется в пользовательском режиме и работает именно в названное число раз быстрее, чем WaitForSingleObject и ReleaseSemaphore, SetEvent и иже с ними, которые работают с "ядреными" объектами...

Ответ на »сообщение 1231« (Cardinal)
___________________________
1) Активности не завязаны на ООП - введена абстракция активной процедуры. Активный объект - это объект-монитор, имеющий одну или несколько связанных активных процедур.
2) В Active Oberon активный объект не может быть собран сборщиком мусора, пока выполняется его активность, т.е. требуется явная остановка циклических активностей. В Active BlackBox имеется механизм корректной автоматической остановки активных объектов, на которые более нет ссылок извне.
3) Введен экспериментальный механизм деталей - так называемая автоматическая агрегация, альтернатива множественному наследованию.

Ответ на »сообщение 1230« (Илья Ермаков)

Однако есть еще одна редкоиспользуемая вещь - очередь асинхронных вызовов потока, APC, которая и позволила сделать быструю реализацию семафоров, на ожидании по Sleep, а не по WaitFor...

Что-то загадочное... я думал Вы на критических секциях сделали.

Ответ на »сообщение 1218« (Илья Ермаков)
___________________________

Ответ на »сообщение 1216« (Как слышно? Приём!)
___________________________
На данный момент решена задача создания многопоточной версии BlackBox. Считанные дни остались до публикации нами расширения Active BlackBox - с поддержкой активных процедур, активных объектов и некоторых других интересных вещей. Функциональность Active Oberon реализована в полной мере, без изменения языка, и с некоторыми дополнительными преимуществами.

Следующая задача - поддержка распределенных вычислений, модели распределенного взаимодействия объектов, объектной базы данных. Это будет выполняться под конкретный проект, на котором и будет испытано. Идей по этому поводу много, но работы пока не начинались, т.к. до создания многопоточной среды писать на Блэкбоксе серверные приложения было невозможно.
Замечательно! А какие дополнительные преимущества?

Ответ на »сообщение 1229« (Как слышно? Приём!)
___________________________
Разница за счет того, что семафоры в Windows являются объектами ядра, и этим все сказано... Каждое обращение к объекту ядра требует порядка 1000 операций, на вход в режим ядра. Семафоры Win не эффективны для межпоточной синхронизации, их назначение - межпроцессная синхронизация. UNIX'ы предоставляют быстрые семафоры пользовательского режима, Win - нет. Из возможностей синхронизации пользовательского режима в Win присутствуют лишь атомарные операции и критические секции. Однако есть еще одна редкоиспользуемая вещь - очередь асинхронных вызовов потока, APC, которая и позволила сделать быструю реализацию семафоров, на ожидании по Sleep, а не по WaitFor...

>>> А вот семафоры ... работают в 12 раз быстрее системных.
Я понимаю, что win must die :) , но за счёт чего такая разница?

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

>>> Камень-ножницы-бумага это скорее всего не классы, а значения.

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

Насчёт "не ввязываться в драку" посмотрите презентацию (370 Кб) по адресу
http://htt-ums.ru/ums-v1.ppt
Там, кстати, есть некие темы, перекликающиеся с решениями Лиспа -
функциональный подход на Обероне.

Ответ на »сообщение 1226« (Илья Ермаков)

А вот семафоры для синхронизации и AWAIT реализованы быстрые, пользовательского режима, работают в 12 раз быстрее системных.

Круто!

Ответ на »сообщение 1224« (Илья Ермаков)

refcnt проверять не надо - это уже делает ThisLoadedMod.

ThisLoadedMod проверяет refcnt на отрицательные значения, а UnloadMod первым делом проверяет refcnt на 0, так что самостоятельно проверять refcnt, действительно, излишне.

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