Everything you thought you knew about .NET Threading is wrong.
A few years ago, everybody used to should about XML and only use XML for everything. It was a good case of people rushing to something because of the hype and using it for scenarios it was not meant to be used.
I have to say I fell for the TPL library hard. It is actually a piece of dirt which has been over hyped and sold as a solution to all threading issues.
Let me make it clear here, the TPL fails miserably because as per the recommendations, we can't set the thread priority without screwing up its internal scheduler, and because we can't do that, if the task contains a for or while loop which loops fast enough the processor will use 100% CPU.
That by itself is not a problem. The issue is because the task runs with normal priority, no other process can get access to the processor easily and things slow down considerably.
Hence, I have tested and verified that if you know that you are going to use a limited number of threads, and you want to split up work which might use 100% CPU, it is better using the classic Thread class instead of the TPL with a thread priority of below normal.
When I do this, stuff which I am running in parallel, runs in parallel, splitting the work load in some cases AND/OR doing two different things which were being doing sequentially before. Even if it uses 99% CPU, the server is responsive to other stuff running on it, and is not super slow like it with with the TPL.
This debacle happens because we have all forgotten that TPL and the thread pool is meant to be used for cases where we want to create many threads and not have to worry about taking care of them. Evidently, now, we have to make sure, these thread pool threads do not do any work which uses too much CPU as well.
My use case is uncommon, but for me, in my application it happens all the time that, I have to do two different things sequentially, and I can easily speed up 2X by running both things in parallel, waiting till both finishes and then moving to the next task.
In the other case, I execute something locally, and also remotely. I can save a lot of time, but doing this in parallel instead of sequentially.
Threads are not always about doing something and then using events to get the results later.
Btb you probably cannot even use the Parallel.For method for the same reason that it uses thread pool threads inside, and you have a classic case here as well.
I have to say I fell for the TPL library hard. It is actually a piece of dirt which has been over hyped and sold as a solution to all threading issues.
Let me make it clear here, the TPL fails miserably because as per the recommendations, we can't set the thread priority without screwing up its internal scheduler, and because we can't do that, if the task contains a for or while loop which loops fast enough the processor will use 100% CPU.
That by itself is not a problem. The issue is because the task runs with normal priority, no other process can get access to the processor easily and things slow down considerably.
Hence, I have tested and verified that if you know that you are going to use a limited number of threads, and you want to split up work which might use 100% CPU, it is better using the classic Thread class instead of the TPL with a thread priority of below normal.
When I do this, stuff which I am running in parallel, runs in parallel, splitting the work load in some cases AND/OR doing two different things which were being doing sequentially before. Even if it uses 99% CPU, the server is responsive to other stuff running on it, and is not super slow like it with with the TPL.
This debacle happens because we have all forgotten that TPL and the thread pool is meant to be used for cases where we want to create many threads and not have to worry about taking care of them. Evidently, now, we have to make sure, these thread pool threads do not do any work which uses too much CPU as well.
My use case is uncommon, but for me, in my application it happens all the time that, I have to do two different things sequentially, and I can easily speed up 2X by running both things in parallel, waiting till both finishes and then moving to the next task.
In the other case, I execute something locally, and also remotely. I can save a lot of time, but doing this in parallel instead of sequentially.
Threads are not always about doing something and then using events to get the results later.
Btb you probably cannot even use the Parallel.For method for the same reason that it uses thread pool threads inside, and you have a classic case here as well.
Comments
Post a Comment