最大线程数
我有一个程序，它接受 2 个 N 位数字，并使用线程和线程将它们相乘。打印输出。
这里创建的线程数量是2 * N - 1。
每当我运行程序 N > 时151，程序给我一个分段错误。
进程可以从线程池获取的最大线程数是否有上限？
如果是这样，这可以成为故障的正当原因吗？
编辑：
Valgrind 发现 N <= 150 没有内存泄漏。
我正在 Linux 2.6.x 内核中运行该程序。
I have a program which accepts 2 N-digit numbers, multiplies them using threads & prints the output.
The number of threads created here are 2 * N - 1.
whenever I run the program for N > 151, the program gives me a segmentation fault.
Is there a cap on maximum number of threads a process can get from the thread pool?
If so, could this be a valid reason for the fault?
Edit:
Valgrind finds no memory leaks for N <= 150.
I'm running the program in Linux 2.6.x kernel.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
默认情况下，每个线程获得 8MB 的堆栈。 300 个线程乘以 8MB 就线程堆栈而言就是 2.4GB - 如果您在 32 位模式下运行，那么这可能是您允许的大部分进程地址空间。
在创建线程堆栈之前，您可以使用 pthread_attr_setstacksize() 将线程堆栈的大小减小到更合理的大小：（
创建一个新的 pthread_attr，然后设置堆栈大小将其传递给
pthread_create）。By default, each thread gets an 8MB stack. 300 threads by 8MB is 2.4GB just for thread stacks - if you're running in 32 bit mode, then that's probably most of your allowed process address space.
You can use
pthread_attr_setstacksize()to reduce the size of your thread stacks to something a bit more sane before you create them:(Create a new
pthread_attr, set the stack size then pass that topthread_create).POSIX 保证您有 64 个线程。更重要的是实施带来的礼物。
POSIX guarantees you 64 threads. More than that is a gift from the implementation.
那将超过 300 个线程！考虑一下处理器不断在它们之间切换并确定它们的优先级以及来自其他应用程序的线程所带来的巨大开销。我认为使用这样的线程是一场即将发生的灾难，并且可能也不会提高您的性能。
我怀疑它们是最大线程数，因为管理它们是 CPU 的工作。我不会使用超过 100 个线程，这是一个非常糟糕的主意。
That would be over 300 threads! Consider the massive overhead from the processor constantly switching between them and prioritizing them, as well the threads from other applications. I think that using threads like that is a disaster waiting to happen, and probably won't help your performance either.
I suspect that their would be a maximum number of threads, considering that it is the CPU's job to manage them. I wouldn't use more that 100 threads, it is very much a bad idea.
如果在 Linux 下：检查
limits.h中的PTHREAD_THREADS_MAX。这是最大值。每个进程允许的线程数。而且：这不应该成为段错误的原因。
If under Linux: Check
PTHREAD_THREADS_MAXinlimits.h. That is the max. allowed thread count per process.And also: this should not be a cause for a seg-fault.
您的问题没有指定操作环境，这是回答您的第一个问题所必需的，但是如果您受 CPU 限制并且您拥有的线程数超过了处理器核心数（大多数笔记本电脑上为 2 或 4） ），那么您可能会浪费资源。
对于第二个问题，不，这不是分段错误的有效原因。假设您出于某种我们不知道的充分原因创建了如此荒谬的线程数量，请仔细检查您的信号量使用情况和资源分配结果。
You question doesn’t specify the operating environment, which is necessary to be able to answer your first question, but if you’re CPU-bound and the number of threads you have exceeds the number of processor cores (2 or 4 on most notebooks), then you’re probably wasting resources.
For the second question, no, it’s not a valid reason for a segmentation fault. Presuming you’re creating this ridiculous number of threads for some good reason that we’re not aware of, double-check your semaphore usage and your resource-allocation results.
我的 Ubuntu 盒子显示的限制为 123858，所以我怀疑你是否遇到了 300，但如果是的话，你的 pthread_create 将返回非零。请务必检查返回值。
使用
-g编译并使用 gdb 运行来调试分段错误，而不是猜测原因。它将向您指出确切的行，并告诉您导致崩溃的确切变量值。我还建议可能存在同步问题，例如缺少互斥体，但如果这是原因，您很可能会看到较小 N 值的问题，尽管不那么频繁。
My Ubuntu box shows a limit of 123858, so I doubt you're running into it with 300, but your pthread_create would return non-zero if you were. Make sure to check the return value.
Compile with
-gand run with gdb to debug segmentation faults instead of guessing at the cause. It will point you to the exact line and tell you the exact variable values that caused the crash.I would also suggestion possible synchronization issues such as missing mutexes, but if that were the cause you would most likely see problems with smaller values of N, although not as frequently.