Awkward Coder

My last post had a comment from @LordHanson about changing the thread priority via the ThreadStart parameter to see if this improved the performance. I made the following small change to include setting the thread priority: This improved the responsiveness of the UI when the number of thread is equal to or greater than the number of logical processors (tested with 2 * System.Environment.ProcessorCount), I still see the UI stuttering & stalling occasionally but it's greatly reduced - happens less than 10% of the time. I then start to wonder is it better from the point of view of total time taken to reduce the concurrency to less than the number of logical processors or to reduce the thread priority. I suppose the answer depends on which technique you want to use, for me there isn't a justifiable reason not to use the Parallel.For from the TPL - it's not a piece of time critical code.

I was wondering on the affects if my previous post was re-written to remove the use of TPL and just use the standard threading classes in the framework instead, would the performance be different. So the previous post was using the following code: When the limited concurrency scheduler is initialised with a number greater than or equal to the number of logical processors then the CPU hits 100% and the app stalls and stutters. If this is re-written without the use of TPL would I get the same results? Re-writing this produced the following code, using a Semaphore to control the number of concurrent threads: In answer to the question, you get exactly the same behaviour, there is no benefit in not using TPL to handle the concurrency - good :)