Quote:
Your readers could spend a lot of time scanning a mostly-empty list, and your writer could spend a lot of time scanning a mostly-full one.
I've accounted for that possibility in the elaborate design of the "task-queues", (trust me on this).
Quote:
That's a lot of time wasted, you'd be much better off just using a normal one-writer-many-reader queue. It won't block when there's lots of work, and will actually put threads to sleep when there's none, instead of everything spinlocking forever.
The "thread-pool" is a customised in design, dedicated for the application sitting atop of it. This application generates a high number of tasks, and possesses much implicit parallelism. I originally used it with existing thread-pools, but found I needed more control over the allocation of "tasks" to "cores", hence I'm making my own. When there is no work it means there is no work in the application, so that's okay.
After reading your post, I think I'll run with the atomics, see how that fares. Thanks for your help (again).