10ms is nearly a whole frame if you're aiming for 60fps. There are basically 4 cases:
Worker thread has work, continues to have work
This works the same way no matter what - the thread processes the work continuously.
Worker thread does not have work, continues to not have work
The pseudo-code in the OP would wake up the thread every 10ms to check if there was work, even if it never got work. A blocking queue would not wake up the thread until there was something in the queue.
Worker thread has work, finishes all work
The worker thread blocks until there's more work. Or just continuously polls until there's more work.
Worker thread does not have work, gets work
With a blocking queue, the moment the thread is running on the CPU it will start processing the work. With polling, it can take up to 10ms for the thread to even realize there's work.
Sleeping in concurrent code instead of using synchronization primitives is almost always a sign of incorrect understanding of how concurrency works. For example, a web server doesn't wake up every n seconds to see if it should serve each page. It waits until there is a request for a page and then immediately starts working on the page.
To be clear, this isn't my original code:
armok-vision/Assets/MapGen/Meshing/BlockMesher.cs at d7381e97bd4f88c1082d49fd65ee5f4bbfd46ded Β· RosaryMala/armok-vision
A 3d realtime visualizer for Dwarf Fortress. Contribute to RosaryMala/armok-vision development by creating an account on GitHub.