Luckily, the Task framework gives you a way to customize scheduling if you're willing to use TaskFactory.StartNew() instead of Task.Run(). The more of these tasks you are juggling at once, the more unwieldy and resource hungry your app can become. One of the main reasons for doing this is performance, but also it can be simply a manageability issue. Even if my app had that many long running CPU bound tasks for some reason I can't fathom, there's no way I'd want to try to execute them all at once! No, what I'd like to do is allocate a certain number of workers, and then dedicate those workers to fulfilling the tasks as the workers become available, so that tasks are waiting in line to be completed, even as more than one are being completed at once. This setup on my system gives me roughly 1023 threads per core, per process in the pool. The ThreadPool as I said, allocates a tremendous amount of threads (or at least stand ins for them) up front and basically takes queuing long operations off the table, because you'll usually have a thread available, even if you don't have an idle core to run it on - or at least this is default behavior.
An I/O bound operation does not tie up CPU cycles (aside from a miniscule bit of overhead to make it work). The distinction is important, because there's good reason to have more I/O bound operations than cores, depending on how many devices you are talking to. Contrast this with an I/O bound operation that spends most of its time waiting on external device interactions like a hard drive's disk reads or a network controller's incoming packets. ** A CPU bound operation is one that ties up your processor, making it crunch on something.
Taskfactory as timer code#
Eventually, I stumbled on TaskScheduler, and even a bit of example code for subclassing it to change the behavior, but otherwise it's not very well documented.
Therefore, I needed something to allow me to use Tasks, but in such a way that I could control how many ran at once. Using the technique I outlined in the previous article works, but it's a bit complicated, and even if it was abstracted, using the Task framework is the way to go these days in. The built in ThreadPool doesn't really care about that, and setting SetMaxThreads() to try to change that impacts the whole process, among other problems. I'd rather prefer to queue operations once I won't get additional performance out of running more of them. The moral of this is create as few threads as you need, but no fewer. In fact, the more threads you have, the harder the scheduler has to work, meaning you're losing performance with more threads than you can even run concurrently on your CPU. NET value I get back for available threads per process seems obscene. The bottom line is, if you have operations that tie up your CPU, you don't gain any performance by running more of them than you have cores to execute them. I'm not sure they're actually created, or if there's just cutouts, but still, an ideally designed application will have exactly as many CPU bound operations going as there are cores (or usually, cores minus one since the primary one is usually concerned with managing everything else, and probably a UI). NET allocates (on my system) 2047 potential threads for CPU bound** operations.
I got into this mess revisting this project but using the Task framework and the built in thread pool.
Once such feature is the TaskScheduler, which controls when your tasks get executed. Some of the best features however, aren't very well documented.
Taskfactory as timer how to#
Often easier to use than threads, they give you at least as much power, if you know how to use them. NET and the TAP programming pattern are very powerful tools to add concurrent execution to your application.
0 kommentar(er)
