14

how can I make a queue thread safe? I need to push / pop / front / back and clear. is there something similar in boost?

I have one producer and one or more consumer.

unikat
  • 341
  • 2
  • 5
  • 14
  • Look into [mutexes](http://vichargrave.com/multithreaded-work-queue-in-c/). – Martol1ni Jan 23 '14 at 07:44
  • 1
    Your title asks if they're thread-safe, yet your opening sentence asks how you can make them so. So you know the answer to the question in the title already. – WhozCraig Jan 23 '14 at 07:46
  • Possible duplicate of: C++11 thread-safe queue (http://stackoverflow.com/questions/15278343/c11-thread-safe-queue) – yasouser Jan 23 '14 at 08:23
  • This blog post talks about it: Implementing a Thread-Safe Queue using Condition Variables (http://www.justsoftwaresolutions.co.uk/threading/implementing-a-thread-safe-queue-using-condition-variables.html). The author of the post is the guy who wrote C++ Concurrency in Action. – yasouser Jan 23 '14 at 08:25

4 Answers4

10

std::queue is not thread safe if one or more threads are writing. And its interface is not conducive to a thread safe implementation, because it has separate methods such as pop(), size() and empty() which would have to be synchronized externally.

A common approach* is to implement a queue type with a simpler interface, and use locking mechanisms internally to provide synchronization.

* A search for "concurrent queue C++" should yield many results. I implemented a very simple toy one here, where the limitation was to use only standard C++. See also Anthony Williams' book C++ concurrency in action, as well as his blog.

juanchopanza
  • 223,364
  • 34
  • 402
  • 480
2

You must protect access to std::queue. If you are using boost protect it using boost::mutex. Now if you have multiple readers and one writer thread look at boost::shared_lock (for readers) and boost::unique_lock(for writer).

However if you will encounter writer thread starvation look at boost::shared_mutex.

mindo
  • 139
  • 4
  • 2
    I doubt that multiple readers can read the queue concurrently and safely. For this question I believe a reader pops items off the queue. A pop operation modifies the queue and therefore must hold an exclusive lock on the queue. In other contexts the word "reader" is used to mean code that performs no modifications and simply looks at values. If in this question the readers are calling peek instead of pop then they satisfy this criteria and shared locks would work. – Jason Aug 02 '14 at 17:14
  • @Jason, one possible solution could be a mutable member flag with an atomic CAS mechanism that allows each reader thread process one unique item in the queue without popping, and a periodic clean-up phase (under an exclusive lock) can help clean up processed items. – Fox Dec 23 '14 at 15:47
1

in boost 1.53 there is a lockfee queue http://www.boost.org/doc/libs/1_53_0/doc/html/boost/lockfree/queue.html, no mutex or smth like this.

Mike Minaev
  • 1,912
  • 4
  • 23
  • 33
0

You have to protect it, e.g. with a std::mutex, on every operation. Boost would be an alternative if you don't have C++11 yet.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • 2
    Even so, some extra synchronization would be required (say you want to check that the queue is not empty before popping. This is not atomic, so could fail even if the individual operations are synchronised). – juanchopanza Jan 23 '14 at 07:52