3 ms·
> if we know that a set of tasks are dependent on each other in ways that aren't visible on the source code, but are known to the programmers, it would make sen
by Const-me 6y ago
> if we know that a set of tasks are dependent on each other in ways that aren't visible on the source code, but are known to the programmers, it would make sense to schedule them on a queue in their own thread
Why it would make sense?
In my experience, dedicated threads only makes sense in very specific use cases. Like dealing with APIs which have thread affinity, or when you want OS to prioritize stuff. Generally, throwing tasks into a shared thread pool is the way to go.
- jcelerier 6y ago> In my experience, dedicated threads only makes sense in very specific use cases. Like dealing with APIs which have thread affinity, or when you want OS to prioritize stuff. well, yes, those are things that happen fairly often. e.g. there's a lot of work on optimizing code for various arm big.LITTLE things, where you have some algorithm that you want to make sure runs on the "big" cores.
- Const-me 6y agoCan’t you use two shared thread pools, with threads affinity set to the big and little parts of the CPU, respectively? I think for most use cases runtime scheduling is better than compile-time one. Because other processes sharing the hardware, and because tasks take unpredictable time, depends on almost everything including ambient temperature. Not to mention compilers don’t generally know count of cores, outside of a few niches like embedded, iOS and consoles games.