1

I wanted to simply write 'Title' but apparently I need at least 30 characters.

Edit: Not a duplicate, I have exactly one producer and exactly one consumer. There will be no double pop or double push conflicts and there will be no accidentally popping an empty queue.

Edit: Since people are incapable of answering the question as it stands, here is pseudocode of the situation I am obviously referring to:

Thread 1:

while (1)
{
    if (!q.empty())
        q.pop();
}

Thread 2:

while (1)
{
    if (the_planets_are_aligned)
        q.push(something);
}
otah007
  • 505
  • 1
  • 4
  • 17
  • Very much time to refresh [how to ask good questions](http://stackoverflow.com/help/how-to-ask), as well as [this question checklist](https://codeblog.jonskeet.uk/2012/11/24/stack-overflow-question-checklist/). And don't forget how to create a [mcve]. – Some programmer dude Sep 05 '19 at 10:09
  • @Someprogrammerdude There is no example. The question is simple and well-formed. All other questions regarding thread-safe queues in C++ are talking about multiple consumers and/or producers. I obviously can't test it myself as it's about thread-safety, I could run a test 1000 times and not hit a race condition by pure chance. – otah007 Sep 05 '19 at 10:15
  • @G.M. See my edit. – otah007 Sep 05 '19 at 10:25
  • 1
    The please edit your question to provide a [mcve] that demonstrates precisely how you intend to use the `std::queue`. If you have separate producer and consumer threads then how do you know there will be `"...no accidentally popping an empty queue"` unless you employ a synchronization primitive such as a mutex? – G.M. Sep 05 '19 at 10:29
  • 1
    You say you "***have*** exactly one producer and exactly one consumer" (emphasis mine). That implies that you have some code. Why not make that existing code your [mcve]? Especially considering that you're leaving out one crucial detail: Is your code threaded or not? Is the consumer one thread and the producer one thread? Then the duplicate very much is valid. The number or consumers or producers is irrelevant to the problem, it can be one each or multiple of each. – Some programmer dude Sep 05 '19 at 10:30
  • @G.M. There will be no accidentally popping an empty queue because there is only one consumer. The consumer checks if the queue is empty. If it's not, it pops an element. Nobody else is removing elements, so if the queue is non-empty it is guaranteed to be non-empty until said consumer pops an element. Because there is only one consumer. It's not rocket science... – otah007 Sep 05 '19 at 10:39
  • Are the producer and consumer operating on the *same* thread or on *different* threads? Please clarify. – G.M. Sep 05 '19 at 10:41
  • @Someprogrammerdude I don't have any code yet. Obviously it's intended to be multithreaded, otherwise I wouldn't be asking about thread safety. And obviously the consumer and producer are in seperate threads, or there couldn't possibly be a thread safety problem. My own code, and whether or not it exists, is irrelevant to the question. For some reason people here don't like answering the question as asked and try to answer something else entirely. – otah007 Sep 05 '19 at 10:41
  • 1
    Then think about what happens if the producer calls `push` and is then preempted (in the middle of the `push` call) and the consumer starts. What is the state of the queue when the consumer want to use it? Short answer: `std::queue` simply isn't thread-safe. The number of threads doesn't matter. – Some programmer dude Sep 05 '19 at 10:42
  • @Someprogrammerdude I don't know that because I haven't looked at the source code for it. Have you? If you can back your statement with evidence, post an answer. And the number of threads does matter, for example 1 thread (which is not applicable to this question). – otah007 Sep 05 '19 at 10:45
  • 1
    `std::thread` is not specified to be thread safe. Implementation doesn't matter (and I doubt any implementation actually adds thread safety to `std::queue` or the underlying container). End of story. – Some programmer dude Sep 05 '19 at 10:55
  • @Someprogrammerdude The fact that you posted that as a comment rather than as an answer betrays your confidence in your remarks. If you don't have any proof then there's no point speculating. – otah007 Sep 05 '19 at 11:59
  • 1
    You can find mentions just about everywhere that the C++ specification makes no guarantees about thread safety. But since they are not part of the C++ specification itself, do you take that as lack of confidence too? The general rules is that if there's no explicit mention about something being thread-safe, you should *always* treat it as thread-unsafe. – Some programmer dude Sep 05 '19 at 13:00

0 Answers0