You had me at "Hello World" : Multi Thread

Fixing the Issue that Does Not Exist

HelloWorld — Thu, 05 Feb 2009 14:06:44 GMT

I spent some time planning on improvements that I wanted to do on one of our project. I reviewed the code that I notice a place where I think I could improve the performance by avoiding locking.

So I wrote the code, and tested it, works great, the new non-locking algorithm works fine. Then when I replaced the old code with my new code and ran my test, to my surprise, it did not behave the way I want it to be. Still works, but the performance and the throughput was not any better. In some cases, it actually yield worse performance compared with the old code.

Curious, I captured the performance counters by running my test app side by side, the one with old code, and the other one with new code.

Look and behold, under extreme cases, the old code has zero Total # of Contentions. The new code, of course has zero Total # of Contentions, and at the same time, consumes more memory due to the lock free algorithm implementation that I chose.

Basically, the lock free code tries to solve a problem that did not exist in the old code. Yes, it uses lock, but the old code runs really fast, and it is very tight, so there was no contention.

Moral of the story, reviewing the code may reveal some issue, put it to test, and verify that the issue is really an issue, before planning any work on it. One good thing, I did not spend too much time on it. :)

When Building Multi-Threaded Applications using ThreadPool, Make the Number of Worker Threads Configurable

HelloWorld — Tue, 16 Dec 2008 14:14:14 GMT

Just a simple thought, when creating a multi-threaded applications, make the number of threads configurable. ThreadPool has this behavior that it will immediately set the minimum worker threads equal to the number of logical processors in your machine, and set the maximum to 250 per logical processor, well documented in msdn (.Net Framework 2.0 SP1).

ThreadPool will create a new thread every half second, also documented in msdn. This behavior could lead to thread explosions, where there are too much threads fighting for limited resources (memory, lock, disk IO, processor, etc.). Your app may run slower if the thread creation is not managed wisely.

It is also a good idea to be able to throttle the application to use fewer threads. It is a good idea to be able to limit the number of threads in the system through configuration. Set the max number of threads by calling SetMaxThreads, and if the config value is less than the number of logical processors, do not forget to call SetMinThreads. Be aware that this can also lead to other issue, like thread starvation.

This is just an idea, if you have been writing multi-threaded applications using ThreadPool, probably you have thought about this already. Keep in mind, your application needs as few thread as possible, but not fewer.