Combine this with Linus's recent rant about how avoiding the kernel during thread synchronization is counter-productive leads me to think that threads + a synchronized queue built with a mutex and a condition variable is simply the simplest and most effective way to go wide.
Implementing an efficient synchronized queue is relatively hard. OSes already have many cross-thread queues in their user-facing APIs.
On Linux I usually use mq_send / mq_receive, on Windows PostThreadMessage/GetMessage, SubmitThreadpoolWork, or PostQueuedCompletionStatus/GetQueuedCompletionStatus. On iOS and OSX there’s grand central dispatch.
Besides the issues like how the return values of size() and empty() can be invalidated before the functions return. And, how it would be nice to have some better support for move semantics in there.
OS queues rarely expose methods like size() or empty(). In their multi-consumer queues they normally only expose variants of enqueue() and dequeue(). Peeking or checking for empty size is only there for single consumer queues, like win32 message queue.
Here’s the implementation of queues in Linux: https://github.com/torvalds/linux/blob/4334f30ebf395b204c6cb... I never worked on that kernel, but on the first sight it looks like they’re using a combination of locks and lock-free stuff there.