为什么在boost:::thread的时候，Valgrind显示出堆栈使用率的增加?

Wrote a simple test:

写一个简单的测试:

#include <iostream>
#include <boost/thread.hpp>

using namespace std;

void myThreadRun() {
    cout << "Thread id: " << boost::this_thread::get_id() << "\n";
}

int main() {
    for (int i = 0; i < 10000; i++) {
        boost::thread t(myThreadRun);

        t.join();
    }

    return 0;
}

on which Valgrind Massif shows the following graph:

在上面，Valgrind Massif展示了如下图:

(The stack profiling was enabled. Platform: Linux Ubuntu x86).

(启用了堆栈分析。平台:Ubuntu Linux x86)。

This program does not actually seem to have memory leaks: the memory usage is stable.

这个程序实际上似乎没有内存泄漏:内存使用是稳定的。

I wonder: is it a problem of Valgrind or boost::thread? Or maybe I misinterpret something?

我想知道:这是一种Valgrind或boost的问题:线程?或者我误解了什么?

How would you explain that?

你怎么解释呢?

2 个解决方案

#1

This isn't boost::threads, it happens with just plain pthreads too. I grabbed the sample program from here (Pthread Creation and Termination), upped the thread count to 1000 and compiled as plain C, and I see the same behavior when processing it with massif. So either it's something in pthreads or something valgrind/massif is doing.

这并不是boost:::threads，它也可以用于普通的pthreads。我从这里获取了示例程序(Pthread创建和终止)，将线程计数提高到1000，并将其编译为普通C，我在使用massif处理它时看到了相同的行为。要么是pthreads中的东西，要么是valgrind/massif的东西。

EDIT: used program (Pthread Joining) as well. See second graph.

编辑:使用程序(Pthread join)。看到第二个图。

Creation and Termination:

创建和终止:

    KB
547.6^                                                                       #
     |                                                                    @@@#
     |                                                                @@@@@@@#
     |                                                             @@@@@@@@@@#
     |                                                          @@@@@@@@@@@@@#
     |                                                      ::::@@@@@@@@@@@@@#
     |                                                  ::::: ::@@@@@@@@@@@@@#
     |                                               @@@::::: ::@@@@@@@@@@@@@#
     |                                           @@@@@@@::::: ::@@@@@@@@@@@@@#
     |                                        @@@@@@@@@@::::: ::@@@@@@@@@@@@@#
     |                                     @@@@@@@@@@@@@::::: ::@@@@@@@@@@@@@#
     |                                @@@@@@@ @@@@@@@@@@::::: ::@@@@@@@@@@@@@#
     |                            @@@@@ @@ @@ @@@@@@@@@@::::: ::@@@@@@@@@@@@@#
     |                         @@@@@ @@ @@ @@ @@@@@@@@@@::::: ::@@@@@@@@@@@@@#
     |                     ::@@@@@@@ @@ @@ @@ @@@@@@@@@@::::: ::@@@@@@@@@@@@@#
     |                  @@@::@ @@@@@ @@ @@ @@ @@@@@@@@@@::::: ::@@@@@@@@@@@@@#
     |               @@@@ @::@ @@@@@ @@ @@ @@ @@@@@@@@@@::::: ::@@@@@@@@@@@@@#
     |           @@@@@@ @ @::@ @@@@@ @@ @@ @@ @@@@@@@@@@::::: ::@@@@@@@@@@@@@#
     |      :::::@@@ @@ @ @::@ @@@@@ @@ @@ @@ @@@@@@@@@@::::: ::@@@@@@@@@@@@@#
     |   :@@: :: @@@ @@ @ @::@ @@@@@ @@ @@ @@ @@@@@@@@@@::::: ::@@@@@@@@@@@@@#
   0 +----------------------------------------------------------------------->Mi
     0                                                                   13.22

Pthread joining, minus the math busy work:

Pthread加入，减去数学繁忙工作:

    KB
548.8^                                                             #
     |                                                           @@#::
     |                                                        :::@@#::
     |                                                     ::::::@@#:::
     |                                                  ::::: :::@@#:::::
     |                                              @@@@::::: :::@@#:::::
     |                                            @@@@@ ::::: :::@@#:::::::
     |                                        :@@:@@@@@ ::::: :::@@#:::::::@
     |                                     @@@:@ :@@@@@ ::::: :::@@#:::::::@
     |                                  :::@ @:@ :@@@@@ ::::: :::@@#:::::::@::
     |                               @@@:: @ @:@ :@@@@@ ::::: :::@@#:::::::@::
     |                            @@:@ @:: @ @:@ :@@@@@ ::::: :::@@#:::::::@::
     |                        @:::@@:@ @:: @ @:@ :@@@@@ ::::: :::@@#:::::::@::
     |                     ::@@:: @@:@ @:: @ @:@ :@@@@@ ::::: :::@@#:::::::@::
     |                  ::@: @@:: @@:@ @:: @ @:@ :@@@@@ ::::: :::@@#:::::::@::
     |               :@@::@: @@:: @@:@ @:: @ @:@ :@@@@@ ::::: :::@@#:::::::@::
     |            @@@:@ ::@: @@:: @@:@ @:: @ @:@ :@@@@@ ::::: :::@@#:::::::@::
     |         @@@@@ :@ ::@: @@:: @@:@ @:: @ @:@ :@@@@@ ::::: :::@@#:::::::@::
     |     @@@:@@@@@ :@ ::@: @@:: @@:@ @:: @ @:@ :@@@@@ ::::: :::@@#:::::::@::
     |   @@@@ :@@@@@ :@ ::@: @@:: @@:@ @:: @ @:@ :@@@@@ ::::: :::@@#:::::::@::
   0 +----------------------------------------------------------------------->Mi
     0                                                                   19.14

It looks like joining should eventually bring the stack size back down, even under valgrind.

看起来，即使是在valgrind下，加入也最终会使堆栈大小降低。

#2

Your code doesn't give the cleanups a chance to happen. When you call join on a thread, it waits until the thread signals completion, not the actual release of all of its resources. If you create the threads more slowly or put a delay or yield in your loop, the "leak" will go away.

您的代码没有提供清理的机会。当您在线程上调用join时，它会等待线程信号完成，而不是所有资源的实际释放。如果您以更慢的速度创建线程，或者在循环中添加延迟或让步，那么“泄漏”就会消失。