concurrent_vector concurrent grow_to_at_least segfaults

[ldalessa]

I have concurrent code that looks like

tbb::concurrent_vector<tbb::concurrent_vector<int>> vec;
...
// in parallel
vec.grow_to_at_least(x + 1);
vec[x].push_back(i);

It's using tbb from libtbb-dev/testing,now 2020.1-2 amd64 [installed] and I'm linking tbbmalloc .

This code periodically segfaults on the push_back as if the grow has returned before indices up to x have been constructed–presumably there's a race with a concurrent grow_to_at_least.

Is this a user error on my part with the grow_to_at_least interface? If so, is there an idiomatic way to concurrently grow such a vector.

[alexey-katranov]

This code periodically segfaults on the push_back as if the grow has returned before indices up to x have been constructed–presumably there's a race with a concurrent grow_to_at_least.

Consider the documentation that grow_to_at_least does not guarantee that elements are really constructed: "Blocks until all elements in range [0..n) are allocated (but not necessarily constructed if they are under construction by a different thread)."

Is this a user error on my part with the grow_to_at_least interface? If so, is there an idiomatic way to concurrently grow such a vector.

Can you provide more details what is the algorithm logic, please?. Do you want to guarantee that vector contains at least x elements at any time moment?

[ldalessa]

Hi Alexey. Indeed, this appears to be a case of user error, thank you.

I will point out however that the link you posted does not contain the language that you quoted (linking to that website is awkward). In particular, the second sentence of the page you linked to says "It is safe to grow a concurrent_vector while other threads are also operating on elements of it, or even growing it themselves."

Later on the page as a caveat to the size() routine, there is the aside "You must synchronize construction and access." Furthermore, there is an easily overlooked subsection which has more detail specifically on my issue. It suggests that threads may return from grow_to_at_least without guaranteeing that elements in the range have been constructed, and suggests polling flags at each location before use. This isn't feasible for my use case, as the element type is tbb::concurrent_vector and I have no good way to poll it to see if it has been fully initialized.

I'd suggest that the obscurity of this information constitutes a tbb documentation bug, particularly given the name of the method grow_to_at_least and the prominent claim that concurrently growing the vector is safe. It would help users if there was an up-front operational specification that details the circumstances under which it is safe to access the vector after growth... e.g., is it safe to access location if they are primitive types? What if they have trivial constructors? Is push_back safe? If it's never safe then is there a tbb linearization algorithm that I can wrap these calls inside, or do I need to implement my own? etc. Alternatively another "Caution" section could be included about the construction issue.

My algorithm is simply a "bucketing" algorithm in a delta-stepping graph implementation, where I'm recording graph vertex ids into the buckets based on their discovered distance. Large distances will require buckets that haven't yet been allocated.

[alexey-katranov]

Yes, it is a good idea to improve the documentation.

[arunparkugan]

@alexey-katranov is this issue is still relevant?