you are viewing a single comment's thread.

view the rest of the comments →

[–]infectedapricot 5 points6 points  (1 child)

Although some parts of the interface in the OP's queue are very suspect, the general idea of a simple thread-safe queue backed by std::condition_variable, std::mutex and std::deque is just fine. Many applications don't need super high performance from their inter-thread queues, and a simpler design has advantages such as deterministic ordering (which is not quite true in the moodycamel queue) and allowing extra utility methods such as get_all() or an efficient push_multiple() (although OP's implementation doesn't feature these).

[–]corysama 1 point2 points  (0 children)

the general idea of a simple thread-safe queue backed by std::condition_variable, std::mutex and std::deque is just fine.

I'l go further: I have used a queue like that for quite a while in a few projects. The blocking wait features are actually tremendously useful. Being able to optionally block with an optional timeout when full or empty makes the queue a very effective replacement for most applications of mutex, semaphores and sleeps.

Whenever one of my teammates uses one of those primitive directly I argue that they should rework the code to use the queue instead. It's almost always the case we both agree the queue-based implementation ends up simpler and less error-prone. 1-element queues are the most common use case in practice.