2

I have a producer/consumer situation with single producer and single consumer, sharing a common std::deque.

Let me write some code:

deque<int> dq;

void producer()
{
for (int i = 0; i < N; i++)
   dq.push_back(i);
   // signal data
}

void consumer()
{
  // get signal
  int n = dq.front();
  dq.pop_front();
}

Consider consumer() and producer() being executed on independent threads. Does this code need synchronization?

M310
  • 397
  • 2
  • 13
  • So, so many duplicates here: http://stackoverflow.com/questions/4105930/is-using-stddeque-or-stdpriority-queue-thread-safe http://stackoverflow.com/questions/1362110/is-the-c-stdset-thread-safe http://stackoverflow.com/questions/4029448/thread-safety-for-stl-queue (Literally 8 seconds of research would give you your answer.) – BTownTKD Apr 09 '14 at 16:38
  • 1
    First quoted question is about only-pushing, second is about std::set, third is about std::queue. I'm asking about std::deque with one only thread that pushes at one side and one only thread that pops at the opposite side with respect the first one. Maybe your search requires more time than 8 seconds. – M310 Apr 10 '14 at 16:57

2 Answers2

2

If you are not synchronizing between readers and writers, there is a possibility of data corruption.

So the answer in general is NO.

To requote

Multiple readers are safe. Multiple threads may simultaneously read the contents of a single container, and this will work correctly. Naturally, there must not be any writers acting on the container during the reads.

Depending on the environment, you can use different concurrent containers. For example, MSDN supports concurrent queue And there are boost libraries which provides lock free containers as well.

Community
  • 1
  • 1
Mohan
  • 1,850
  • 1
  • 19
  • 42
0

Generally, no, your code is not thread-safe.

See relevant documentation for MSVC ("Thread Safety in the C++ Standard Library"):

If a single object is being written to by one thread, then all reads and writes to that object on the same or other threads must be protected. For example, given an object A, if thread 1 is writing to A, then thread 2 must be prevented from reading from or writing to A.

Or for GCC ("Concurrency > Containers")

[...] locking must nearly always be done outside the container, by client code (that'd be you, not us).

The C++ standard (even the C++11 one) does not mandate thread-safe access here. If you use some other compiler, its documentation will surely tell you something similar about concurrent access to container classes.

Christian Hackl
  • 27,051
  • 3
  • 32
  • 62
  • But for especially a deque, wouldn't it be safe to read the front element of a deque with a raw pointer to the element value (not iterator), while pushing back from another thread? "Iterator validity for push_back : All iterators related to this container are invalidated. Pointers and references to elements in the container remain valid, referring to the same elements they were referring to before the call." http://www.cplusplus.com/reference/deque/deque/push_back/ – shadow_map Feb 01 '17 at 09:03