crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

> Boost thread - ограниченное количество потоков?, непонятное ограничение, не связанное с ресурсами системы
Iron Bug
  опции профиля:
сообщение 6.2.2009, 11:23
Сообщение #1


Профессионал
*****

Группа: Модератор
Сообщений: 1611
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 219 раз(а)




Репутация:   12  


добрый день всем.
вот, может, кто сталкивался с подобной проблемой:
использую библиотеку thread boost'а для кроссплатформенного программирования. до недавего времени всё было замечательно, но тут возникло одно неприятное открытие:
оказалось, что буст почему-то ограничивает возможное количество потоков. а именно: после создания какого-то числа работающих потоков создание очередного потока проваливается с исключением boost::thread_resource_error и до уменьшения количества работающих потоков создание нового потока невозможно (каждый раз выпадает это исключение). причём это максимальное число потоков не зависит от реальных ресурсов системы, либо зависимость мне непонятна.
для проверки была написана маленькая программа - генератор потоков. потоки просто создаются, спят какое-то время, потом завершаются. потоки пустые, мелкие - то есть, памяти теоретически должно хватать. при этом задавалось разное время жизни потоков и разное количество потоков. результаты по подсчёту количества потоков всегда одинаковы, независимо от времени жизни каждого потока. это число каким-то загадочным образом зависит от машины, но, по видимому, не зависит от количества свободной памяти процесса и системы.
из опытов получилась такая странная картина: дома стоит машина под линюксом, 4 гектара памяти, своп вообще не используется - опытным путём получен предел в 382 потока, на работе машина под вендой, 1 гектар памяти, предел - 2024 потока. увеличение-уменьшение количества других процессов в системе никак не влияет.
откуда берутся такие странные цифры? может, есть возможность определить каким-то образом, как распределять ресурсы, чтобы потоков было больше? по работе необходима возможность одновоеменного выполнения очень большого и заранее неопределённого количества потоков в риал-тайме (пул потоков как бы не подходит по замыслу задачи). непонятно, откуда исходит это ограничение и как с ним бороться (если это вообще возможно).
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
 
Начать новую тему
Ответов
ViGOur
  опции профиля:
сообщение 6.2.2009, 11:33
Сообщение #2


Мастер
******

Группа: Модератор
Сообщений: 3296
Регистрация: 9.10.2007
Из: Москва
Пользователь №: 4

Спасибо сказали: 231 раз(а)




Репутация:   40  


Все правильно, это ограничение потоков, для винды это выставляется в реестре.
Цитата
Какие существуют ограничения на количество потоков в программе?
Разумно предположить, что количество потоков в процессе ограничено ресурсами самого процесса, а так же ресурсами ядра операционной системы.

ПРИМЕЧАНИЕ
Все сказанное ниже справедливо для линейки Windows NT/2000/XP.

Один из основных ресурсов ядра операционной системы, потребляемый при создании потока, это невыгружаемая памяти (non-paged memory) ядра. Создание одного потока требует около 12 килобайт невыгружаемой памяти. Ограничения на размер пула невыгружаемой памяти устанавливается в следующем ключе системного реестра:

HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management

параметрами NonPagedPoolQuota и NonPagedPoolSize. Их значение по умолчанию равно нулю, что отдает управление этими значениями в руки операционной системы.

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

Как известно, каждому процессу выделяется адресное пространство в четыре гигабайта, но под свои нужды процесс может употребить только первые два гигабайта. Собственно из этих двух гигабайт и выделяется память под стек для вновь создаваемого потока. Размер стека определяется двумя факторами - параметром /STACK линковщика и параметром dwStackSize функции CreateThread.

Размер стека, заданный параметром dwStackSize, не может быть меньше, чем указано в параметре /STACK линковщика и по умолчанию равен ему. Размер стека, используемый линковщиком по умолчанию равен одному мегабайту. Таким образом максимальное количество потоков, которые можно создать при всех параметрах заданных по умолчанию, равняется примерно 2035. По достижении этого предела функция CreateThread начинает возвращать ошибку ERROR_NOT_ENOUGH_MEMORY, что является истинной правдой - если умножить количество потоков на размер стека по умолчанию, то как раз получается примерно два гигабайта - размер адресного пространства отданный процессу на карманные расходы.

Обойти это ограничение можно указав меньший размер стека параметром /STACK линковщика или в Project Settings (Link/Output/Stack Allocations/Reserve) в Microsoft Visual C++. Размер стека указывается в байтах. Меняя это значение надо быть осторожным ввиду того, что стек используется не только для хранения адресов возврата функций и передачи параметров, но и для хранения локальных переменных. Однако это тема отдельного разговора.


Для линукса также можно настроить это дело, но как не знаю.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

Сообщений в этой теме
- Iron Bug   Boost thread - ограниченное количество потоков?   6.2.2009, 11:23
- - ViGOur   Все правильно, это ограничение потоков, для винды ...   6.2.2009, 11:33
- - Iron Bug   да сомневаюсь я, что это ограничение по памяти. в ...   6.2.2009, 11:45
- - Litkevich Yuriy   Цитата(Iron Bug @ 6.2.2009, 14:43) что эт...   6.2.2009, 11:50
- - ViGOur   Цитата, которую я привел справедлива для Win32 Api...   6.2.2009, 11:52
- - Iron Bug   пока что происходят странные вещи: при УВЕЛИЧЕНИИ ...   6.2.2009, 11:56
- - Litkevich Yuriy   Цитата(Iron Bug @ 6.2.2009, 14:56) могу т...   6.2.2009, 12:04
- - Iron Bug   дык вот не смешно совсем. пока в песочнице копошиш...   6.2.2009, 12:41
- - ViGOur   Как решишь проблему опиши как решил, а то больно и...   6.2.2009, 13:00
- - some_x   Цитата(Iron Bug @ 6.2.2009, 14:23) добрый...   22.2.2009, 0:00
- - ViGOur   Цитата(some_x @ 22.2.2009, 0:00) хотя воз...   22.2.2009, 10:08
- - Andrew Selivanov   #include <stdio.h> #include <windows.h...   20.3.2009, 14:38
- - Iron Bug   Цитата(Andrew Selivanov @ 20.3.2009, 16:3...   20.3.2009, 15:41
- - Andrew Selivanov   Ааа.. стало яснее, но картину в целом всё равно пр...   20.3.2009, 16:18
- - Tonal   Ежели железки тестируются независимо, то действите...   21.3.2009, 10:06
- - Iron Bug   To Andrew Selivanov: Руссинович у меня есть, но д...   23.3.2009, 10:14
|- - Andrew Selivanov   Цитата(Iron Bug @ 23.3.2009, 10:14) To An...   23.3.2009, 18:52
|- - Влад   Iron Bug, вот я прочел и так и не понял: зачем все...   23.3.2009, 22:27
|- - Stranger   Цитата(Влад @ 23.3.2009, 22:27) Iron Bug,...   21.5.2009, 17:17
- - Tonal   Erlang таки не скрипт а виртуальная машина. Заточе...   23.3.2009, 12:42
- - Iron Bug   ну, тут много деталей... если даже виртуальная маш...   23.3.2009, 15:23
- - ViGOur   Цитата(Andrew Selivanov @ 23.3.2009, 18:5...   23.3.2009, 23:52
- - Litkevich Yuriy   Цитата(ViGOur @ 24.3.2009, 2:52) Возьмем ...   24.3.2009, 3:04


Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 25.11.2024, 21:14