Writing multithreaded code is just as easy as writing data access code or writing file IO code with .net. I believe that so long as you have a solid understanding of the threading object model, how that model is suppose to work and some common implementation techniques of the model it will be easy. I think this way about all object oriented code. Object oriented thread programming is no different than object oriented database programming. It’s just code.
The difference is that threading presents a unique set of challenges that are a little more complicated to grasp up in the brain. Threading adds an additional dimension to your programming. It fundamentally changes the pallet from a linear 3D surface to a rich, non-linear 4D surface.
Hmm… 3D, 4D… I might have just confused some people (we aren’t talking graphics :p ), so let’s get into the dimensions of programming.
· Polymorphic Class
These dimensions are surfaces in object oriented programming that we use in conjunction with Boolean logical and flow control to make the computer do things. Most people have no trouble wrapping their mind around these baseline 3 dimension
Things start to get complicated mentally when you add the fourth dimension, time; AKA threading. With the three ‘standard’ dimensions time is assumed at linear. This means that you can start walking through your code line by line and guarantee that on the time scale code will execute in order, one instruction after the next; statement by statement.
Threading turns this linear operations mindset upside down. When you incorporate threading into an application you are creating multiple timelines of execution. The secret to threading is learning how to manage the intersection of these timelines.
When you frame the issues of threading into the context of managing timelines, you can take a solid knowledge of the treading object model and develop incredibly effective solutions ‘easily’. Hopefully what follows will demystify the subject of threading.