Maximum number of threads

Question

I have a program that takes 2 N -digit numbers, multiplies them by streams and outputs the result.

Number of threads created: 2 * N - 1 .

whenever I run a program for N > 151 , the program gives me a segmentation error.

Is there a limit on the maximum number of threads that a process can receive from a thread pool?

If so, could this be a good reason for rejection?

Edit:

Valgrind does not detect memory leaks for N <= 150 .

I run the program in the Linux 2.6.x kernel.

Answer 1

By default, each thread receives a stack of 8 MB. 300 threads per 8 MB is 2.4 GB for thread stacks - if you work in 32-bit mode, then this is probably most of your allowed process address space.

You can use pthread_attr_setstacksize() to reduce the size of the thread stacks to something more reasonable before creating them:

 int pthread_attr_setstacksize (pthread_attr_t *__attr, size_t __stacksize) 

(Create a new pthread_attr , set the stack size, then pass it to pthread_create ).

Answer 2

POSIX guarantees you 64 threads. Moreover, this is a gift from the implementation.

Answer 3

It will be more than 300 threads! Consider massive processor overhead, constantly switching between them and prioritizing them, as well as threads from other applications. I think that the use of such flows is a catastrophe awaiting its appearance, and probably also will not help your performance.

I suspect that this will be the maximum number of threads, given that it is the task of the CPU to manage them. I would not use more than 100 threads, this is a very bad idea.

Answer 4

If on Linux: check PTHREAD_THREADS_MAX in limits.h . This is max. The number of threads for each process is allowed. And also: this should not be the reason for the failure of seg.

Answer 5

You ask if the operating environment indicates which is necessary to answer your first question, but if you are connected to the processor and the number of threads that you have exceeds the number of processor cores (2 or 4 on most laptops), then you probably spend resources.

In the second question, no, this is not a valid cause of segmentation error. Assuming you're creating this ridiculous number of threads for some good reason you weren't aware of, double-check the semaphore usage and resource allocation results.

Answer 6

My Ubuntu field has a limit of 123858, so I doubt that you ran into it with 300, but your pthread_create will return a non-zero value if you were. Be sure to check the return value.

Compile with -g and run with gdb to debug segmentation errors rather than guessing for this reason. It will tell you the exact string and tell you the exact values ​​of the variables that caused the failure.

I would also suggest possible synchronization problems, such as missing mutexes, but if that were the reason, you would most likely see problems with lower N values, although not so often.