OberonCore
https://forum.oberoncore.ru/

Активные процедуры.
https://forum.oberoncore.ru/viewtopic.php?f=31&t=446		 Страница 1 из 1
Автор:  slava [ Четверг, 03 Май, 2007 20:16 ]
Заголовок сообщения:  Активные процедуры.
Какое максимальное количество 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 корректным?

Спасибо.
Автор:  Борис Рюмшин [ Четверг, 03 Май, 2007 20:38 ]
Заголовок сообщения: 
Поведение:
Цитата:
OS Restrictions
Unable to create new thread because of operation system restriction.
Send your claims to operation system developers.

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

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

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

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

В силу ряда причин с января активным ядром не занимался вообще. Скоро буду доделывать - и выпускать релиз. Кстати, будет open-source.
Автор:  Сергей Губанов [ Четверг, 03 Май, 2007 20:52 ]
Заголовок сообщения: 
Борис Рюмшин писал(а):
Это ограничение почему-то накладывается ОС.


Наверное считается что в ОС предназначенной для домашнего/офисного использования столько много потоков не нужно. А кому нужно, пусть покупают серверную версию ОС уже за совершенно другие деньги :D :D :D
Автор:  Илья Ермаков [ Четверг, 03 Май, 2007 21:09 ]
Заголовок сообщения: 
От как это так не надо? Как это так не надо в домашней ОС?
"Одна жена готовит, одна стирает, одна шьет, одна детей кормит..."
(С) БСП
:-)
Автор:  slava [ Четверг, 03 Май, 2007 21:37 ]
Заголовок сообщения: 
Что-то не вяжется...

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

Комп и ОС, разумеется, те же.
Автор:  Илья Ермаков [ Четверг, 03 Май, 2007 21:47 ]
Заголовок сообщения: 
Не вяжется, потому что потолок в системе - не на сами потоки, а, видимо, на хэндлы объектов ядра.
А активные объекты кушают приличное количество хэндлов семафоров. Причем более одного на объект - еще и на каждый ожидающий объект, и т.п.
Вот прикиньте это количество - и понижение потолка вполне объяснится.

Я гарантирую одно - то, что в момент трепа 100 новый поток РЕАЛЬНО создать уже нельзя, CreateThread дает ошибку. А почему там он дает ошибку - нюансы поведения ОС.
Автор:  batyrmastyr [ Четверг, 03 Май, 2007 22:38 ]
Заголовок сообщения: 
Илья Ермаков писал(а):
...
Ибо от мейнстрима гиперпараллельности не дождемся, у них просто фантазии не хватает, что можно писать столь сильно распараллеленный код. Абстракции Явы и Шарпа не тянут :-)

Мэйнстрим, похоже, просто уверен, что те кому надо больше тупо создадут еще один процесс с виртуальной машиной Java в нём :) .
Илья Ермаков писал(а):
....
В силу ряда причин с января активным ядром не занимался вообще. Скоро буду доделывать - и выпускать релиз. Кстати, будет open-source.

Хм, а потом еще думать, как его интегрировать его с ядром BB1.6. :wink:
Автор:  Илья Ермаков [ Четверг, 03 Май, 2007 22:59 ]
Заголовок сообщения: 
Там в 1.6 в ядре не так много изменений...
Собственно, об соответствии 1.6 я буду думать сразу.
Кроме того... скажу по секрету, что ядро будет порезано :-) На части... Идем в сторону супермикроядерности :-)
Автор:  batyrmastyr [ Четверг, 03 Май, 2007 23:17 ]
Заголовок сообщения: 
Илья Ермаков писал(а):
Там в 1.6 в ядре не так много изменений...
Собственно, об соответствии 1.6 я буду думать сразу.
Кроме того... скажу по секрету, что ядро будет порезано :-) На части... Идем в сторону супермикроядерности :-)

буду ждать появления целой подсистемы Kernel вместо одного файла?, авось тогда у меня хватит мозга чтобы в нем разобраться :)
Автор:  Илья Ермаков [ Пятница, 04 Май, 2007 00:25 ]
Заголовок сообщения: 
Да там все не так сложно... Я тоже долго боялся, прежде чем параллельность делать :-)

Кстати, к АктивББ прилагается полная документация на интерфейс ядра - все мои наблюдения...
Автор:  Кривохатько С.А. [ Пятница, 04 Май, 2007 01:11 ]
Заголовок сообщения: 
Илья Ермаков писал(а):
Не вяжется, потому что потолок в системе - не на сами потоки, а, видимо, на хэндлы объектов ядра.
А активные объекты кушают приличное количество хэндлов семафоров. Причем более одного на объект - еще и на каждый ожидающий объект, и т.п.
Вот прикиньте это количество - и понижение потолка вполне объяснится.

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


Здесь пишут, что причина в банальной нехватке адресного пространства:
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.
Автор:  Илья Ермаков [ Пятница, 04 Май, 2007 01:43 ]
Заголовок сообщения: 
Да, спасибо за информацию, надо будет попробовать!
Мне сейчас гораздо интереснее, как это дело поведет в себя в Линуксе. На количество процессов в Линуксе потолок вроде бы 1000, но каков потолок на потоки...
Автор:  Wlad [ Вторник, 08 Май, 2007 12:42 ]
Заголовок сообщения: 
Кривохатько С.А. писал(а):
Но есть ложка дёгтя:
Windows 2000/NT and Windows Me/98/95: The STACK_SIZE_PARAM_IS_A_RESERVATION flag is not supported.

Вообще-то странно!
Я когда на QNX отлаживал свою многострадальную библиотеку активных объектов (а-ля Активный Оберон над Си++) - для отладки задавал десятки тысяч потоков...
Х-мммм....
Автор:  Кривохатько С.А. [ Вторник, 08 Май, 2007 16:13 ]
Заголовок сообщения: 
Wlad писал(а):
Кривохатько С.А. писал(а):
Но есть ложка дёгтя:
Windows 2000/NT and Windows Me/98/95: The STACK_SIZE_PARAM_IS_A_RESERVATION flag is not supported.

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


Адресное пространство для пользовательского режима в Win ограничено 2ГБ. Из-за особенностей реализации - минимальный размер одного куска из этих 2ГБ - 64КБ. Получается порядка 30000.
В QNX получается намного больше?
Автор:  batyrmastyr [ Вторник, 08 Май, 2007 21:47 ]
Заголовок сообщения: 
Илья Ермаков писал(а):
Да, спасибо за информацию, надо будет попробовать!
Мне сейчас гораздо интереснее, как это дело поведет в себя в Линуксе. На количество процессов в Линуксе потолок вроде бы 1000, но каков потолок на потоки...

В свежих ядрах (если не ошибаюсь, с 2.4, а может и 2.2) на хранение идентификаторов процесса и потока стали отводить 4 байта вместо 2-х. Думаю слепить 65к потоков там уже не проблема.
Автор:  Wlad [ Четверг, 10 Май, 2007 10:14 ]
Заголовок сообщения: 
Кривохатько С.А. писал(а):
Адресное пространство для пользовательского режима в Win ограничено 2ГБ. Из-за особенностей реализации - минимальный размер одного куска из этих 2ГБ - 64КБ. Получается порядка 30000.
В QNX получается намного больше?

Число 30000 - это ОЧЕНЬ запредельно для винды. Впрочем - и для Линукса. Для QNX грубо можно оценить по перемножению системных ограничений (максимальные показатели) количество одновременно запускаемых процессов на максимальное количество потоков на один процесс. Это ОЧЕНЬ много. И самое приятное, что оно таки-да - будет выполняться! ОЧЕНЬ медленно (почти мёртво), но ВСЕ потоки гарантированно будут живыми и система не рухнет.
(Кстати, у меня полтора года комп с QNX просто не выключался и почти каждый день на нём отлаживались драйвера. Учтите - БЕЗ ПЕРЕЗАГРУЗКИ! :о)
Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/