Максимальное количество потоков

У меня есть программа, которая принимает 2 N-значных числа, умножает их с помощью потоков и распечатывает результат.

Количество созданных потоков 2 * N - 1.

всякий раз, когда я запускаю программу для N > 151, программа выдает ошибку сегментации.

Есть ли ограничение на максимальное количество потоков, которое процесс может получить из пула потоков?

Если да, то может ли это быть уважительной причиной неисправности?

Изменить:

Valgrind не обнаруживает утечек памяти для N <= 150.

Я запускаю программу на ядре Linux 2.6.x.


c pthreads segmentation-fault
person Community    schedule 02.10.2010    source источник

Ответы (6)


arrow_upward
10
arrow_downward

По умолчанию каждый поток получает стек размером 8 МБ. 300 потоков на 8 МБ - это 2,4 ГБ только для стеков потоков - если вы работаете в 32-битном режиме, то это, вероятно, большая часть разрешенного адресного пространства процесса.

Вы можете использовать pthread_attr_setstacksize(), чтобы уменьшить размер стеков ваших потоков до более разумного, прежде чем создавать их:

int pthread_attr_setstacksize (pthread_attr_t *__attr, size_t __stacksize)

(Создайте новый pthread_attr, установите размер стека и передайте его в pthread_create).

person caf    schedule 02.10.2010
comment
Теперь, когда я проверил, pthread_create не позволит создать 303-й поток pthread, хотя я сбросил размер стека до 80 байтов. - person ; 02.10.2010
comment
Есть ли какие-то другие ограничения на размер ресурсов, которые также необходимо уменьшить? - person ; 02.10.2010
comment
@crypto: если вы попытаетесь уменьшить размер стека ниже PTHREAD_STACK_MIN (16384 в Linux), pthread_attr_setstacksize() не удастся, и он продолжит использовать тот же размер. Попробуйте установить приличное значение (например, 65536). - person caf; 02.10.2010
comment
@crypto: вы всегда должны проверять возвращаемое значение функций, которые вы вызываете, включая pthread_create () и pthread_attr_setstacksize (). Это сэкономит ваше время в долгосрочной перспективе. - person ninjalj; 02.10.2010

arrow_upward
2
arrow_downward

POSIX гарантирует вам 64 потока. Более того, это подарок от реализации.

person David Schwartz    schedule 15.08.2011

arrow_upward
1
arrow_downward

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

Я подозреваю, что это будет максимальное количество потоков, учитывая, что задача процессора - управлять ими. Я бы не стал использовать более 100 потоков, это очень плохая идея.

person Alexander Rafferty    schedule 02.10.2010

arrow_upward
1
arrow_downward

В Linux: отметьте PTHREAD_THREADS_MAX в limits.h. Это макс. допустимое количество потоков на процесс. А также: это не должно быть причиной неисправности.

person Mario The Spoon    schedule 02.10.2010

arrow_upward
1
arrow_downward

В вашем вопросе не указана операционная среда, которая необходима для ответа на ваш первый вопрос, но если вы привязаны к ЦП и количество имеющихся у вас потоков превышает количество ядер процессора (2 или 4 на большинстве ноутбуков) ), то вы, вероятно, зря тратите ресурсы.

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

person danorton    schedule 02.10.2010

arrow_upward
1
arrow_downward

В моем поле Ubuntu указано ограничение в 123858, поэтому я сомневаюсь, что вы столкнетесь с ним с 300, но ваш pthread_create вернет ненулевое значение, если вы это сделаете. Обязательно проверьте возвращаемое значение.

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

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

person Karl Bielefeldt    schedule 02.10.2010