OberonCore

Какое максимальное количество thread'ов (активных процедур) можно создать в ActiveBB ?
Является ли это ограничение жёстким/мягким ? Зависит от версии ОС или ещё то чего ?

Я запустил следующий тест: создаются N активных процедур с N очередями сообщений между ними, образующими цикл (ring). Каждый thread чего то посылает одному соседу и получает от другого через эти каналы.

Тест работает при N=500, а при N=600 валится, выскакивает окошко с сообщением:
OS Restrictions
Unable to create new thread because of operation system restriction.
Send your claims to operation system developers.

Нажимаю на OK, вылетает TRAP 100 в Kernel.cCreateTask.
Window Task Manager показывает: Threads=584. При закрытии ActiveBB'а, число Threads медленно уменьшается (-1 в сек).

Как мне кажется 500 активных процедур это слишком мало, можно ли что-то с этим сделать? Является ли поведение ActiveBB корректным?

Спасибо.

Поведение:

является корректным.

Это ограничение почему-то накладывается ОС. И данное сообщение - реакция АББ на это ограничение.

Чуть точнее ответит Илья, когда появится.

Поведение с выбросом окна и трепом - корректно.
При определенном числе открытых хэндлов ОС на очередной CreateThread возвращает ошибку. В этот момент и вылетает окошко сообщения, а после закрытия модального диалога - откат по инварианту из cCreateTask.
На Windows 2000 Server потолок побольше - порядка 900 потоков, на Вин 2000 Проф - поменьше, порядка 400. На Линуксе, надо ожидать, будет тоже в районе 900.
Нужно больше? Портирование Черного Ящика в Голубую Бутылку - вот она, наша надежда
Ибо от мейнстрима гиперпараллельности не дождемся, у них просто фантазии не хватает, что можно писать столь сильно распараллеленный код. Абстракции Явы и Шарпа не тянут

Поведение с остановкой объектов - если они не отрабатывают сигнал ShouldComplete, то остановка идет медленно... Среда выдает стоп-сигнал, ждет, убивает, дает сигнал следующему... Надо просто цикл переделать - чтобы сразу выдать всем сигнал, подождать и всех прибить махом...

В силу ряда причин с января активным ядром не занимался вообще. Скоро буду доделывать - и выпускать релиз. Кстати, будет open-source.

Наверное считается что в ОС предназначенной для домашнего/офисного использования столько много потоков не нужно. А кому нужно, пусть покупают серверную версию ОС уже за совершенно другие деньги

От как это так не надо? Как это так не надо в домашней ОС?
"Одна жена готовит, одна стирает, одна шьет, одна детей кормит..."
(С) БСП

Что-то не вяжется...

Есть прога написанная на MFC (я её немного корректировал, используется для тестирования сервера на stress), так она создала 1000 thread'ов без проблем. TaskManager это подтвердил.
Правда на 2000 загнулась (TaskManager показал что создались только 1968).

Комп и ОС, разумеется, те же.

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

Я гарантирую одно - то, что в момент трепа 100 новый поток РЕАЛЬНО создать уже нельзя, CreateThread дает ошибку. А почему там он дает ошибку - нюансы поведения ОС.

Мэйнстрим, похоже, просто уверен, что те кому надо больше тупо создадут еще один процесс с виртуальной машиной Java в нём .

Хм, а потом еще думать, как его интегрировать его с ядром BB1.6.

Там в 1.6 в ядре не так много изменений...
Собственно, об соответствии 1.6 я буду думать сразу.
Кроме того... скажу по секрету, что ядро будет порезано На части... Идем в сторону супермикроядерности

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

Да там все не так сложно... Я тоже долго боялся, прежде чем параллельность делать

Кстати, к АктивББ прилагается полная документация на интерфейс ядра - все мои наблюдения...

Здесь пишут, что причина в банальной нехватке адресного пространства:
http://blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspx

И говорят, что можно увеличить кол-во потоков до 13000 если использовать:
HANDLE h = CreateThread(NULL, 4096, ThreadProc, NULL, STACK_SIZE_PARAM_IS_A_RESERVATION, &id);

Попробуете на досуге в Active BlackBox?

P.S.
Но есть ложка дёгтя:
Windows 2000/NT and Windows Me/98/95: The STACK_SIZE_PARAM_IS_A_RESERVATION flag is not supported.

Да, спасибо за информацию, надо будет попробовать!
Мне сейчас гораздо интереснее, как это дело поведет в себя в Линуксе. На количество процессов в Линуксе потолок вроде бы 1000, но каков потолок на потоки...

Вообще-то странно!
Я когда на QNX отлаживал свою многострадальную библиотеку активных объектов (а-ля Активный Оберон над Си++) - для отладки задавал десятки тысяч потоков...
Х-мммм....

Адресное пространство для пользовательского режима в Win ограничено 2ГБ. Из-за особенностей реализации - минимальный размер одного куска из этих 2ГБ - 64КБ. Получается порядка 30000.
В QNX получается намного больше?

В свежих ядрах (если не ошибаюсь, с 2.4, а может и 2.2) на хранение идентификаторов процесса и потока стали отводить 4 байта вместо 2-х. Думаю слепить 65к потоков там уже не проблема.

Число 30000 - это ОЧЕНЬ запредельно для винды. Впрочем - и для Линукса. Для QNX грубо можно оценить по перемножению системных ограничений (максимальные показатели) количество одновременно запускаемых процессов на максимальное количество потоков на один процесс. Это ОЧЕНЬ много. И самое приятное, что оно таки-да - будет выполняться! ОЧЕНЬ медленно (почти мёртво), но ВСЕ потоки гарантированно будут живыми и система не рухнет.
(Кстати, у меня полтора года комп с QNX просто не выключался и почти каждый день на нём отлаживались драйвера. Учтите - БЕЗ ПЕРЕЗАГРУЗКИ! :о)