Let's take as example the std::list, let's suppose for a moment that the stl implementation it's thread safe,
some problem arise:
- If it's not needed to be thread safe you will get extra not needed overhead
- What shall do a thread calling a std::list::pop_back on an empty list?
- Waiting for a std::list::push?
- Returning with an "error"?
- Throwing an exception?
- Waiting for a certain ammount of seconds that an entry is available?
- It should be used in an enviroment with a single producer/single consumer, in this case it's possible to implement it without locks.
- Shall be multiple readers permitted?
Yes sure you can solve all the points above with a policy template, but just imagine your users complains.
Well, again, get over it, STL standardized is not thread safe you have to create your thread safe list embedding a real std::list, after all making a wrapper around an STL container is a so easy exercise that if you find difficult to do it yourself then you have to ask: "Am I ready to start with multithreading programming" even if someone provides me an out of the shelf std::list thread safe?
Consider that two different instance of STL containers can be safely manipulated by different threads.
PS: I have written about std::list instead of the most widely used std::vector because std::vector for his own characteristics has to be used in a more "static" way with respect to an std::list and using an std::vector as a container used by multiple threads (producer/consumer) is a plain wrong choice.