One of the good things .net has brought to vb programmers is the ability to very easily do some asynchronous work using the ThreadPool. One of the bad thing .net has brought to vb programmers is the ability to very easily do some asynchronous work using the ThreadPool – huh?
I was reviewing some code recently that was written by somebody that must have been doing some of their first multi-threaded work. .Net has made this type of work pretty easy to pull off. Unfortunately, it can be so easy to jump in this pool (pun intended), that it can be tempting to do so before you learn to swim. There are some basics swimming lessons that should be required before entering the water:
- Know what a critical section is, what a mutex is, and why you need to worry about this; in VB you should be familiar with the words Synclock and Monitor.
- Know what a deadlock is and how it can be prevented. Be particularly conscience of the type of work you are doing within an asynchronous thread handler. You should not wait on the results of additional asynchronous work within an asynchronous handler; be sure to know why this.
- Don’t explicitly share a DB connection between threads. Explicitly open and close short-lived db connections, and let ADO.net take care of the connection pooling for you.
The list of basics really goes on further, but these seem to be some common things I’ve seen people miss when first starting to work with the thread pool. In fact, all three of these were missed/abused in the code I mentioned that I was recently reviewing.
A good MSDN article to get you started with some of the basics can be found here.