Deadlock in tbb::concurrent_vector

[npotravkin]

Summary

Deadlock in tbb::concurrent_vector occurs in simplest example

Version

2021.13

Environment

The following information is important:

• Intel Xeon Gold 6248R CPU
• Windows 10 Enterprise LTSC
• Microsoft Visual Studio Version 17.9.7

Observed Behavior

deadlock occurs in simplest example

Expected Behavior

absence of deadlock

Steps To Reproduce

Code example

#include "random"
#include "oneapi/tbb/parallel_for.h"
#include "oneapi/tbb/concurrent_vector.h"

std::mt19937_64 gen;

int main()
{
constexpr int max_grow_by = 32;
constexpr int n_inserts = 1024;
constexpr int n_repits = 1024*128;// *1024;
auto rand = std::bind(std::uniform_int_distribution {1, max_grow_by }, std::ref(gen));

std::vector<int> n_grow_by(n_inserts);
for (int iter = 0; iter < n_repits; ++iter) {
    std::generate(n_grow_by.begin(), n_grow_by.end(), rand);
    tbb::concurrent_vector<double> vec;
    tbb::parallel_for<int>(0, n_inserts, [&](int i) {
        vec.grow_by(n_grow_by[i]);
    });
}

return 0;

}

[bluescarni]

Hello!

I think I ran into this issue in one of my projects. I do not know if this is useful, but here is a backtrace of my application after it locked up with a few threads busy spinning:

https://gist.github.com/bluescarni/5fee529d4dd0c3929f92ba8e7d265387

Threads 4, 5, 19 and 27 all seem to be deadlocked in concurrent_vector::grow_by().

[aleksei-fedotov]

Hello!

I think I ran into this issue in one of my projects. I do not know if this is useful, but here is a backtrace of my application after it locked up with a few threads busy spinning:

https://gist.github.com/bluescarni/5fee529d4dd0c3929f92ba8e7d265387

Threads 4, 5, 19 and 27 all seem to be deadlocked in concurrent_vector::grow_by().

Hello, Francesco! It seems you run a python script? Not sure if you are able to check the patch, as it only requires to re-build the object files that use tbb::concurrent_vector. But if you do, it would be good to know whether it helps in your case or not.

[bluescarni]

Hi @aleksei-fedotov !

The backtrace is from a computationally-heavy math/physics library which is mostly implemented in C++, with a thin Python layer on top for interactivity. When I took the backtrace, I was running my application within a jupyter lab session - hence the additional threads with several references in the backtrace to Python and ZMQ.

To be clear, the deadlock happens in the C++ code, and there is no parallelism or multithreading happening on the Python side, everything that has to do with threads and TBB is only within pure C++ (EDIT: I am also not trying to access the Python interpreter from multiple threads or anything like that)

Not sure if you are able to check #1532, as it only requires to re-build the object files that use tbb::concurrent_vector. But if you do, it would be good to know whether it helps in your case or not.

I can grab from the patch only the parts affecting the header file and I should be good to go right (without rebuilding TBB)?

I will try to give it a go later today - in order to trigger the issue and grab the backtrace I reported here, I had to run my code for several minutes.

[aleksei-fedotov]

@bluescarni,

I can grab from the patch only the parts affecting the header file and I should be good to go right (without rebuilding TBB)?

Yes, you don't need to rebuild TBB, but you need to rebuild project files (i.e., translation units) that directly or indirectly include and make use of tbb::concurrent_vector.