Почему Valgrind показывает увеличение использования стека с помощью boost:: thread?

Написал простой тест:

#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;
}

на котором Valgrind Massif показывает следующий график:

Valgrind Massif profiling result for the above example

(Профилирование стека включено. Платформа: Linux Ubuntu x86).

У этой программы фактически нет утечек памяти: использование памяти стабильно.

Интересно: это проблема Valgrind или boost:: thread? Или, может быть, я что-то неправильно понял?

Как вы это объясните?

Ответы

Ответ 1

Это не boost:: threads, это происходит и с простыми pthreads. Я схватил образец программы из здесь (создание и завершение Pthread), увеличил количество потоков до 1000 и скомпилировал как простой C, и я вижу то же самое поведение при обработке его массивом. Таким образом, либо это что-то в pthreads или что-то valgrind/massif делает.

EDIT: используемая программа (Pthread Joining). См. Второй график.

Создание и завершение:

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

Соединение Pthread, минус математическая занятая работа:

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

Похоже, что соединение должно в конечном итоге привести к уменьшению размера стека, даже под valgrind.

Ответ 2

Ваш код не дает очисткам шанс произойти. Когда вы вызываете join в потоке, он ожидает, пока поток сигналов не завершится, а не фактический выпуск всех его ресурсов. Если вы создаете потоки медленнее или поместите задержку или результат в своем цикле, "утечка" исчезнет.