Re: Concurrent Containers
"Joshua Maurice" <joshuamaurice@gmail.com>
However, some
of the newer Java containers, which Scott mentions, such as
ConcurrentHashMap, do offer useful functionality, such as an atomic
"put entry in map if not present". I've made use of that function
several times.
Sure, the progress with the collections is clear -- just they are still no
silver bullets (obviously) and can't replace the missing design elements.
A blocking queue for multiple consumers and multiple consumers would
be nice too.
This far it did not fit too well with the STL approach. As current STL is
full of copy operations -- and my queues were more likely holding pointers.
With allocation ownership issues placed to different parties. I was meny
times tempted to use some smart pointers there, especially shared_ptr, then
dropped it.
For other cases the payload supported swap, and that was used for good.
As move semantics enter, the picture may change here.
IIRC, Java has several flavors here, such as one with a
capped size based on an array - attempts to push to a full queue
blocked the producer, and another with a limitless size so that the
producer is never blocked.
See, the proliferation starts here. And in C++ you should add a policy for
move, a policy for allocation/destroy (that could be different that the
%$#@#%$ allocator<> we carry around). How far we got in practice with
customizable things in std this far? After all we can create a locale and
imbue it in a stream, can we? ;-o