STL containers are not thread-safe!
itcecsa
to be used in multi-threaded environment, all the containers must be used in
a wrapped thread-safe mechanism. is there a thread-safe STL container
library existing? or the next C++ standard will support thread-safe
containers?
--
[ comp.std.c++ is moderated. To submit articles, try posting with your ]
[ newsreader. If that fails, use mailto:std-cpp...@vandevoorde.com ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Daniel Krügler
Am 07.06.2011 21:04, schrieb itcecsa:
>
> to be used in multi-threaded environment, all the containers must be used in
> a wrapped thread-safe mechanism. is there a thread-safe STL container
> library existing? or the next C++ standard will support thread-safe
> containers?
For C++0x there are no special containers suggested that provide
special thread-safety guarantees (except for the basic guarantees that
apply for all library components). I'm not aware of any new proposals
for the next technical revision, so if you have good ideas, I can only
encourage you to make such a proposal.
HTH & Greetings from Bremen,
- Daniel Krügler
Anthony Williams
itcecsa <itc...@gmail.com> writes:
> to be used in multi-threaded environment, all the containers must be used in
> a wrapped thread-safe mechanism. is there a thread-safe STL container
> library existing? or the next C++ standard will support thread-safe
> containers?
What does it mean for an STL container to be thread safe?
Thread-safety requires careful thought about what operations can be done
concurrently, and what the consequences are. A thread-safe container
likely has a different interface to a non-thread-safe one.
Libraries such as TBB do provide some thread-safe containers. No doubt
some will be proposed for the next C++ standard.
Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++0x thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
cpp4ever
On 07/06/11 20:04, itcecsa wrote:
>
> to be used in multi-threaded environment, all the containers must be used in
> a wrapped thread-safe mechanism. is there a thread-safe STL container
> library existing? or the next C++ standard will support thread-safe
> containers?
I'm not fully up to date with the next C++0x release, but I think it
will contain thread classes, so creating your own standard thread safe
containers should be easier.
Joshua Maurice
On Jun 7, 12:04 pm, itcecsa <itce...@gmail.com> wrote:
> to be used in multi-threaded environment, all the containers must be used
in
> a wrapped thread-safe mechanism. is there a thread-safe STL container
> library existing? or the next C++ standard will support thread-safe
> containers?
If you are discussing classes like Java java.util.Vector, then I
suggest you review the literature on why java.util.Vector and the rest
of the "implicitly synchronized" Java container classes are a bad
idea.
Most code needs to guarantee certain invariants are true, and they use
locks to maintain these invariants between critical sections. In
short, providing atomic operations on containers like lists and
std::vectors and such would not alleviate the need for a lock and a
critical section. In other words, most critical sections have
sufficiently complex invariants so that simple atomic operations on
containers would be insufficient to do anything useful. Thus, by
requiring the operations to be "atomic", you've accomplished nothing
useful, and have actually pessimized your performance.
/Off the top of my head/, in my very limited experiences, the only
really useful, commonly useful, internally synchronized containers are
queues and maps, such as java.util.concurrent.ConcurrentHashMap.
AFAIK, the internals may be better optimized than simply having a
single lock guarding the entire operation, so it makes sense here, and
I definitely would not want to try to write such things, much
preferring to use a pre-rerolled standard "atomic" queue and "atomic"
map.
Dave Abrahams
> to be used in multi-threaded environment, all the containers must be used in
> a wrapped thread-safe mechanism. is there a thread-safe STL container
> library existing? or the next C++ standard will support thread-safe
> containers?
it's possible to be less thread-safe than int, consider a type where
copies of an object share some mutable state with it].
Also, adding locking at container granularity is generally wasteful,
because when you want to compose two containers into a larger data
structure, the locking doesn't compose in any useful way. If there's
some invariant between the containers (say, they always have equal
length), then broken invariants will be exposed to other threads unless
you add an additional layer of locking... at which point the inner locks
are wasted.
Cheers,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com