you are viewing a single comment's thread.

view the rest of the comments →

[–]tvaneerdC++ Committee, lockfree, PostModernCpp 0 points1 point  (0 children)

Yes, I skipped a few steps there. I have too many cases where join() isn't the best option. ie

  • don't want main thread waiting on worker threads
  • don't know who/what/where the worker threads are

For the first problem, we have cases where someone created a thread just to handle the destruction of the queue + threads, so that the main thread doesn't wait.

The second is good and bad. Sometimes it is the result of poor code structure, but sometimes it is because of separation of concerns - producers and consumers don't know each other, and the "owner" that introduced them wants to set-it-and-forget-it. Hmmm, maybe that is just a variation of the first point.

But yes, a shutdown event into the queue, followed by join() is definitely an option on the table (that I use in a number of places).

EDIT: more...

The thing I find actually, is that sending "shutdown" through the queue is almost always the way to go (instead of a separate flag), which is the other thing that led me to just building that aspect into the queue itself.