Re: Concurrent Containers
"Scott Meyers" <NeverRead@aristeia.com>
Please define 'correct' for the scope of your discussion.
Correct means what it always means: the API does what it promises (e.g.,
all invariants and postconditions are satisfied). For example, if I have
a ConcurrentSet that tells me I may concurrently perform multiple inserts,
after the concurrent inserts are done, I should find exactly one copy of
each thing that was inserted and zero copies of things that were not
As a transaction must involve them together, something a collection can
more in the way than helps. Generally.
Concurrent containers don't claim to solve all concurrency problems, nor
do they promise that clients will never have to worry about concurrency
issues (including transactional issues such as you mention). They simply
promise that certain kinds of operations that would not normally be safe
if performed concurrently on a non-concurrent container are safe on the
concurrent container. So a concurrent queue (useful for producer/consumer
systems) permits enqueue and dequeue operations to proceed concurrently.
A concurrent hash table (potentially useful for, e.g., a cache shared
across threads) might permit concurrent insertions.
A *lot* of effort has gone into developing concurrent containers in Java
and .NET, as well as in C++ libraries such as TBB and PPL. To suggest
that all that effort has been misguided, because there are no common use
cases for such containers, is untenable.
Appears I compressed my thoughts too far, to lose essential elements.
And possibly captured the scopoe of your question incorrectly too.
I was thinking in the scope of a (possible) C++ standard. The problem is
exactly what you emphasice above. A *lot* of effort was put in that field.
And the results are not so bright even in their native environment. But
IMO (!_ even if the results were perfect in java/C#, poted to the C++
environment would not be good enough.
Especially compared to to effort of a creating them by hand.
IMO people who can pick java, will do so. Those who use C++ do that for
reasons like they need the control and performance.
Having some collection that can magically withstand all kinds of operations
from random threads looks really nice. Really. Having some time I'd jump
on it to analyse how it is done and applaud.
But I doubt I'd use such a generic solution in my app. Because having random
threads keep poking a shared collection sounds like a blasphemy. With MT
design we fight to limit sharing as much as possble, for good reasons.
Sharing objects, sharing operations, etc. And using a proper sync op
around what remains shared is not a problem, especially since RAII was
invented to guard the mutex lock.
And going back to the C++ standard, the people creating it (I guess) have
fragment of resources that owners of java and C# has at disposal.
That is why I don't expect to see it there anytime soon (read: in my
And I see the lack of 'de facto standard' going to similar causes.
The java way is to have everything and the pussycat in the lib. The lib is
written by Sun. Or was to yesteryear. And it is considered good enough.
C++ users have no such supplier, and on the other end are more picky. Both
in width and limits of expectations. After all the 'you don't pay for what
you don't use' is still in place. As I can visualize the implementtion of
a concurrent container, and its actual use in a real program -- I'm skeptic
whether it can hold.
To put it another way, in my view in the C++ environment the idea has a bad
tradeoff. But I do not claim my view to be some objective truth, neither
shall it be extrapolated outside its scope.
Boost covers so much stuff and has that fine selection of developers. And it
does have components for both threading and collections. But not for
concurrent collections. My explanations to "why" is that people there also
found it a poor tradeoff. I'm open to hear any other explanation.
And rereading the initial post, your question was what is the menu, not why
is it so thin -- sorry to kinda sidetrack it.