Why stl is not thread safe

So from the above, Yes it is thread safe in GCC to have concurrent reads of same object from multiple threads. I want to ask whether a problem may occur during reallocating of vector to a larger memory block, if there are some child working threads left from the previous update. If you are using a container from multiple threads and at least one thread may perform some action that may modify the state of the container, access to the container must be synchronized.

In the case of std::vector , anything that changes its size notably, insertions and erasures change its state, even if a reallocation is not required any insertion or erasure requires std::vector 's internal size bookkeeping data to be updated. When the producer needs to add more data, it can dynamically allocate a new std::vector with a new, larger size and copies of the elements from the old std::vector. If you are passing your structures around and assigning them in some way to variables or pass-by-value parameters no ref or out keywords then a copy is being used.

Of course, this means that any changes made to the copy are not reflected in the original structure, but it's something to be aware of when passing them around. If you are accessing the structure directly in a manner that doesn't involve copy-by-value semantics e.

In most containers, threads are reused via thread pools and thus are never gc. Static variables are NOT allocated on the stack. Your parallel loop will access each element only once, and hence only from one thread.

There's space in the standard for the member functions of containers to be non-thread-safe. So I doubt that there's a problem in this case, but I haven't looked for the guarantee [edit: rici found it]. It would be safe for an array of bool , since the different elements of that are different "memory locations" 1. STL vector and thread-safety. Asked 6 Months ago Answers: 5 Viewed times. Yes, this would be very bad.

Ravinder Kumar. Only authorized users can answer the question. Please sign in first, or register a free account. Not the answer you're looking for? Related Answers. The former is, of course, the most robust; but the latter can be smaller and faster in an environment where thread safety is never an issue, because all threading code is omitted. Multithreaded is the usual default. Atomic operations on these objects, such as calls to getc and putc , are protected against simultaneous access from different threads.

Assume a int with initial value '0'. One thread WILL always read the value. Other thread MAY write a value '1'. Here all I care is whether the value is '0' or not. Is this fine without a lock or atomic operation? Again one thread WILL always read. The other thread WILL always write.

But nothing is over written nor deleted. Is this thread safe. If any of the above is not safe, what would be the best way to gain maximum performance with less overhead? Other thread MAY write a value '1' This is, by definition, a data race, which is a form of undefined behavior.