当前位置: 首页 > 知识库问答 >
问题:

pthread\u create使用EAGAIN失败

庾勇军
2023-03-14

考虑下面的代码片段,我试图创建一组线程,这些线程最终处理模拟竞争条件的给定任务。

const int thread_count = 128;
pthread_t threads[thread_count];

for (int n = 0; n != thread_count; ++n)
{
    ret = pthread_create(&threads[n], 0, test_thread_fun, &test_thread_args);
    if( ret != 0 )
    {
        fprintf( stdout, "Fail %d %d", ret, errno );
        exit(0);
     }
 }

事情通常工作正常,除了偶尔pthread_create失败与errno EAGAIN"资源暂时不可用",我尝试诱导usap,并重试创建但没有真正的效果。

故障是零星的,在一些盒子上没有故障,在一些盒子上发生得非常频繁。

知道这里会出什么问题吗?

编辑-1

更新最大线程数

cat /proc/sys/kernel/threads-max
256467

编辑2

我认为这里的输入让我思考,我可能会做下面的事情,并发布任何值得分享的结果。

  1. 将堆栈大小设置为最小值,我不认为thread_function使用任何大数组。
  2. 增加我的记忆和交换(并抵消任何副作用)
  3. 编写一个脚本来监控系统行为,并在运行此案例时查看任何其他进程/系统守护进程正在干扰,这反过来又会导致资源紧缩。
  4. 系统的硬限制和软限制相当高,所以我将在这一点上保持不变。

共有3个答案

缪晋
2023-03-14

在shell中选中ulimited-a。您可能在登录策略中设置了进程限制,Linux可笑地将其应用于线程。

唐元青
2023-03-14

您可能对每个进程的最大线程数有系统限制。请尝试使用:cat /proc/sys/kernel/threads-max查看它

颛孙麻雀
2023-03-14

如果您的程序确保它永远不会创建超过系统限制允许的线程(通过在创建新线程之前加入线程),那么您可能会遇到这个内核错误:

  • 任务资源分配前发出任务退出信号,导致伪EAGAIN错误

使用某些类型的容器技术,竞争窗口似乎要大得多,并且错误更容易触发。(这可能取决于使用的cgroup类型。)

 类似资料:
  • 我有一个在linux系统上运行的多线程linux应用程序 该应用程序已经在不同的Linux系统和内核中成功工作,而从未注意到这个问题。 我们目前正在使用这个内核 我们已经使用这个内核1年了,没有问题。 应用程序可以有一些外部连接的客户端。当客户端连接每个客户端的几个线程时,就会创建一个客户端。 最近我遇到了一个问题,pthread\u create return EAGAIn。我设法设计了一个压力

  • 我有以下代码: 我不明白为什么在thr\u num=291的情况下运行此代码时,会出现一个错误:pthread\u create failure,I=291,errno=11(EAGAIN) 使用thr_num=290工作正常。我在Linux-0.2默认值(SLES 11)上运行此代码2.6.27.54rlim.rlim_currlim.rlim_max值6906。我在“最大用户进程”的“ulim

  • 我正在运行以下程序。它只会创建直接消亡的线程。 我发现,在93到98次(略有不同)成功调用之后,对pthread\u create()的下一次调用都会失败,错误为11:资源暂时不可用。我认为我正在正确关闭线程,因此它应该放弃它拥有的任何资源,但有些资源变得不可用。 程序的第一个参数允许我设置调用pthread\u create()的间隔,但通过使用不同的值进行测试,我了解到间隔并不重要(好吧,我会

  • 我正在实现一个UNIX域套接字进程间通信代码,在试图从套接字读取时,我随机地碰到了这个错误--“errno 11:资源暂时不可用”。我使用MSG_PEEK从套接字读取字节数,并为接收缓冲区分配字节数,并读取实际数据。 套接字是一个阻塞套接字,我没有任何非阻塞的代码(总之,接受/读/写)。在阻塞套接字读取中,有什么可能导致这种情况的指针吗?在MSG_PEEK的手册页中,当socket标记为非阻塞时,

  • 问题内容: pthread问题: 似乎只有在其他线程调用pthread_cond_notify之前调用pthread_cond_wait时,条件变量才起作用。如果在等待之前以某种方式发生通知,则等待将卡住。 我的问题是: 什么时候应该使用条件变量? 调度程序可以抢占线程,并且在等待之前可能会发生通知。 等待信号量没有这个问题-它们有一个计数器。 什么时候条件变量比信号量更好? 这是一个测试: 文件

  • 问题内容: 我在Linux上的一个项目使用阻塞套接字。事情是非常连续地发生的,因此非阻塞只会使事情变得更加复杂。无论如何,我发现经常一个调用返回与设置为。 该页面只真正提到了非阻塞套接字的这种情况,这是有道理的。使用非阻塞,套接字可能会或可能不会,因此您可能需要重试。 是什么原因导致套接字阻塞? 我可以做些什么来避免它? 目前,我要处理的代码看起来像这样(我在出错时抛出了异常,但除此之外,它是一个