4 ms·
It looks like the number of threads in the threadpool is fixed. If have 1 one thread in the thread pool, is it possible to dead lock it by queuing a Task A the
by MarkSweep 7y ago
It looks like the number of threads in the threadpool is fixed. If have 1 one thread in the thread pool, is it possible to dead lock it by queuing a Task A the blocks waiting for Task B to do something, where A starts executing before B?
Do you think it would make sense to dynamically adjust the number of threads in the pool? An example of a thread pool that dynamically adjusts the number of threads is .NET. The algorithm is described by Matt Warren[1] and a paper[2]. In addition to the C++ version Matt links to, there is a C#[3] implementation.
[1]: https://mattwarren.org/2017/04/13/The-CLR-Thread-Pool-Thread-Injection-Algorithm/ https://mattwarren.org/2017/04/13/The-CLR-Thread-Pool-Thread...
[2]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.487.7627&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.487...
[3]: https://github.com/dotnet/corert/blob/master/src/System.Private.CoreLib/src/System/Threading/ClrThreadPool.HillClimbing.cs https://github.com/dotnet/corert/blob/master/src/System.Priv...
- carllerche 7y agoThe expectation is that all code running on the Tokio scheduler does not block and does not do anything CPU intensive. There is follow up work planned to allow annotating blocking / CPU intensive bits of code so that the scheduler can do something smarter (things like you linked). The old scheduler already had such an annotation, but in the interest of shipping, this has punted in the new scheduler.
- ulber 7y agoIs that expectation wrt. responsiveness guarantees? In other words, if I'm just interested in throughput are CPU intensive tasks a problem? For example, my expectation is that it would be appropriate to use the new Tokio scheduler to parallelize a compute intensive simulation workload (where inside a "frame" responsiveness is not a problem).
- carllerche 7y agoThe Tokio scheduler uses cooperative multitasking (non-preemptive). So, if your task runs without yielding it can prevent other runnable tasks from executing. So, if that is acceptable, then it is fine.
- weavie 7y agoIs there a recommended approach to dealing with the occassional cpu intensive task? Supposing you were running an http server and most responses were very quick - but occassionally a request came along that required calculating pi to the n billionth digit.. (for example).. Would you need to farm that request to a separate process - or could you keep it in process but in a separate thread outside of Tokio?
- nicoburns 7y agoI believe tokio-threadpool is designes for this scebario.
- carllerche 7y agoRight now, CPU intensive code blocks or code blocks that block need to be annotated. This way, the scheduler can respond accordingly (cooperative).
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]