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
inserted.
So, if we had a ConcurrentQueue, it would not really fit its most likely MT
use case. That includes alerting the consumer on produce...
If you don't mind sidetracking, could you make up a real use case for the
example set you described above? Anything that I could think keeps ringing
'race condition'. If I left the set pray to threads, how can I learn the
postcondition.invariant is actually held? How do I know something is in
there?
Possibly my mind is too petrified to abandon 'you shall lock at least till
the if() part finishes, but more likely until the whole conditional.
Ot it is part of the supposed API to invoke equivalent of java's
synchronized(mySet) { } ?
As a transaction must involve them together, something a collection can
offer is
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).
That sounds like pair<mutex, somecollection> where I can skip locking the
mutex some 30% of the times.
No pun intended, I just try to match the thing with the good advise 'make
interfaces easy to use correctly and hard to use incorrectly'.
Practice shows just too many incorrect uses -- so the main defense is to
avoid the situations altogether.
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.
As mentioned above that is nice but redundant in most actual uses, where you
couple some cond/event.
My designer's guess would say the demand is for not a concurrent queue as a
generic container, but for a X-producer/Y-consumer message queue, covering
those very use cases.
A concurrent hash table (potentially useful for, e.g., a cache shared
across threads) might permit concurrent insertions.
Try to imagine this interface, Could work if:
- no item invalidation (though delete allowed)
- fetch makes copy or uses refcounting (or no delete allowed at all, making
it one-way).
Don't you feel it a fragile element?