STL container's read-only operations

views:

224

answers:

+1 Q:

STL container's read-only operations

Need advice here: which of the STL container's operations are considered read-only? Take vector<int> as example, would it be safe to say that any operation that does not alter the underlying int data is read-only? I am writing a multi-threaded program, but not too sure if it is thread-safe to pass container by reference/pointer.

Between, will the same rules apply to basic_string as well? Any recommended resource that helps for quickly gaining understanding on internal mechanism of STL container? Thanks.

+1 A:

The Standard says nothing on the safety of containers, by the way. But a method marked with const is guaranteed to not modify the container.*

If thread's will be reading and writing to the data at the same time, you'll need to synchronize them.

*Logically modify, that is. Though I don't know any containers off-hand, any mutable members can change in const methods.

GMan 2009-11-26 06:19:25

All the Microsoft containers have optional checked iterators (on by default) that modify the container when an iterator is created or destroyed. See http://msdn.microsoft.com/en-us/library/aa985965%28VS.80%29.aspx

Stephen Nutt 2009-11-27 00:41:37

Use pthread read-write locks in multi-threading threading environment while operating on stl containers. They are quite efficient. Reference for pthread read -write locks:

Pthread Read Write Locks - Yolinux

Vivek 2009-11-26 06:26:10

+1 A:

Methods declared const most likely won’t modify the container, although you can’t be sure.

When using STL containers in a multithreaded application you will need an external synchronization mechanism. The C++ standard library is not thread safe, and any use from multiple threads without synchronization will result in undefined behavior, assuming that one of the threads change the state of the vector object.

lkristjansen 2009-11-26 06:30:34

That explains the reason why I try to find out which operation is non-threadsafe. Although STL is not designed to be threadsafe, I believe not all container operations have multi-threading issue, which some of them probably does not require locking/sync.Or... will it be practical to apply sync for all operations on shared container (i.e. performance consideration)?

shiouming 2009-11-26 07:41:59

The problem is that you cannot know if it thread safe or not, since the standard don’t mention it. So the best practice would be to always use some form of synchronization. You could also find a library supporting thread safe containers. Intel TBB is Open source.

lkristjansen 2009-11-26 08:31:27

Or just check the documentation of your implementation. The standard leaves thread safety unspecified; that explicitly leaves open the possibility that implementations do specify it. Using a thread-safe C++ implementation is a much smaller step then migrating to Intel TBB.

MSalters 2009-11-26 09:47:47

This is true, but will result in non-portable code.

lkristjansen 2009-11-26 10:40:45

True, but the same applies if you use Intel TBB: you can't port that to AMD TBB either. The point of sticking to a standard library implementation is that you can switch to any other thread-safe implementation, and still have the same API.

MSalters 2009-11-26 13:45:10

Comparing the option of apply synchronization on all container operations, with the use of library, I wonder which of them is the more common approach. Wouldn't there be significant performance drawback for the former?

shiouming 2009-11-26 13:45:30

The only thing which is mentioned in standard is

Multiple readers are thread safe (duhhhhhh)
Multiple writers to different containers are thread safe(again duhh...but a smaller one :) this means that no implementation can have static members modification of which can compromise thread safety

Yogesh Arora 2010-01-19 06:13:50

ansaurus

tags:

views:

answers:

STL container's read-only operations

related questions