Thread safety for STL queue

As others have already mentioned, standard containers are not required to guarantee thread safety so what you're asking for cannot be implemented portably. You can reduce the time your reader thread is locking the writers out by using 2 queues and a queue pointer that indicates the queue that is currently in use by the writers.

Each writer would:

• Acquire lock
• Push element(s) into the queue currently pointed to by the queue pointer
• Release lock

The reader can then do the following:

• Acquire lock
• Switch queue pointer to point to the second queue
• Release lock
• Process elements from the first queue

Any type that doesn't explicitly state its thread-safety guarantees should always be controlled by a mutex. That said, your implementation's stdlib may allow some variation of this — but you can't know for all implementations of std::queue.

As std::queue wraps another container (it's a container adapter), you need to look at the underlying container, which defaults to deque.

You may find it easier, better, or more portable to write your own container adapter that makes the guarantees you need. I don't know of anything that does this exactly for a queue in Boost.

I haven't looked at C++0x enough to know if it has any solution for this out-of-the-box, but that could be another option.

This is absolutely implementation-dependent. The C++ standard makes no mention about threads or thread safety, so whether or not this will work depends on how your implementation handles queue elements.

In your case, the reader is actually popping the queue, which is considered a write operation. I doubt any of the common implementations actually guarantee thread-safety in this case, when multiple threads simultaneously write to a container. At least VC++ does not:

For reads to the same object, the object is thread safe for reading when no writers on other threads.

For writes to the same object, the object is thread safe for writing from one thread when no readers on other threads.