Re: Concurrent Containers
"Scott Meyers" <NeverRead@aristeia.com>
Although C++0x includes support for concurrency, it offers no standard
containers that support simultaneous readers and writers. Java and .NET
developers have them as part of their standard libraries (e.g., Java's
Concurrent HashMap and ConcurrentLinkedQueue, .NET's ConcurrentQueue and
ConcurrentBag),
I'm light on java but what I picked up about 'concurrent' containers, (and
even more generally about using threads) is pretty sour. The early
collections with everything synchronizes did not solve any real life use
case but introduced slowdown. Later the programs were full of undefined
behavior due to race conditions. LAter people swithhed to the 'concurrent'
stuff thet converted UB to exceptions thrown here there and everywhere.
In sunmmary I saw only different flavors of broken software, and supposed
'architects' fighting to shuffle bugs around. Instead of looking at the
fundamental issue/root cause: lack of MT design and lack of even recognition
that one is needed. After all tha language is 'safe' and the tools have
all thet 'synchronized' or 'concurrent' names.
:-(((
C/C++ was at least still put in some hurdles to infest a program with
threads, and left some sanity.
but, from what I can tell, there don't even seem to be any de facto
standard concurrent containers for C++ developers. For example, Boost
doesn't seem to offer any.
Is there such thing at all? Now really.
I try to recall my own stuff: I used 'concurrent' queue, in fact many
flavors of it, to communicate between threads. Despite it being
ubiquitous as usage pattern I hardly have in in a stock library, but put
together one in the new arena. Tuned to the actual way of use, and
properties of payload.
And observed others do in a similar way.
As far as the standard: it failed miserably on the much simpler case to
give us a *string*...
On this topic I'd rather keep is conservative and teach people thinking MT,
and able to use the elements in combination. I see the chances to mess up
that way is lower than it would be from picking supposedly pre-assembled
elements.