concurrent_vector

concurrent_vector

Raf Schietekat的头像

A vector is contiguous* but may be reallocated when elements are added; a concurrent_vector is not necessarily contiguous but elements stay put (unless compact()/shrink_to_fit() is called).

I ran into an inconsistency in the signature for grow_to_at_least(): it lacks the prototype parameter that grow_by() does have, which restricts its use to element types with default constructors. Some of the area may already exist, some may be being constructed by another thread, but it does happen that the caller is responsible for constructing new elements, so why not accept a prototype? Can this be explained or addressed?

* Well, only since C++03, which annoyingly neglected to follow through with the addition of operations to assume or give up a dynamically allocated array that even the otherwise infuriating CORBA mapping has and that would make vector a valid alternative to a smart pointer for arrays that C++ intentionally omits. So the significancy of that imposed contiguity without at the same time forbidding non-minimal capacities that sometimes requires subsequent compaction workarounds (test size() and capacity(), then maybe make temporary local vector, reserve, copy, swap) or now perhaps shrink_to_fit() calls eludes me...

7 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项
jimdempseyatthecove的头像

Why not use a vector of pointers to the objects (or references if you wish). Then you will not have the issue of default constructor or any of the other nasties when changing the size of the container.

Jim Dempsey

www.quickthreadprogramming.com
Raf Schietekat的头像

That would be a lot of overhead for some types. But it's just an incidental remark, because concurrent_vector is not really a viable bucket implementation for sample sort for another reason: it also does not offer access to its contiguous subranges (to allow memcpy() of trivially copyable types).

(Added) Please ignore the typo in the original posting, which apparently cannot be edited.

jimdempseyatthecove的头像

Raf, your initial concerns were with vectors containing elements with non-default constructors. Therefore, do not make issue with (POD) types having default constructors. You are looking for one size fits all. You could create a shell template my_concurrent_vector that has two ctors, one without prototype parameter and one with prototype parameter. Then depending on which, create vector of POD's or vector of pointers to more complex objects.

Jim Dempsey

www.quickthreadprogramming.com
Raf Schietekat的头像

Sure, but I'm writing a function template where I don't know the actual type; I'm already making a special effort just to find out whether the type is trivially copyable (I've published a snapshot of the code), and even that isn't perfect. Perhaps you could whip out some metaprogramming detection mechanism for classes with or without a default constructor, but I'm not sure how or even whether this can be done, and I already have another reason not to use concurrent_vector for that purpose so I'm not going to try.

But my question was more for the TBB team, to explain or remove the inconsistency, not so much for a workaround.

jimdempseyatthecove的头像

Raf,

I agree, there should be orthogonality. There should be more compelling reason for removing a design feature than "I haven't seen it used".

Jim Dempsey

www.quickthreadprogramming.com
Alexey Kukanov (Intel)的头像

We did not manage to recall or find out why in TBB 2.1 the overload that uses copy constructors was added for grow_by but not grow_to_at_least. Maybe a customer asked to improve the former call but not the latter, and we just overlooked the introduced inconsistency.

Off the top of my head, I have no reasons not to add such an overload. I will add it to the list of possible concurrent_vector improvements. It's unlikely to be implemented soon, though.

登陆并发表评论。