Back in the day when I was a greenhorn COM developer – I had a question pop up in my head every time I was tasked to work on something that needed to be multithreaded.
It’s a theory I used to have in my novice days. Let’s take a multithreaded application example and dissect a certain aspect of it.
Here’s the true story behind this technobabble… About 7 or 8 years ago I was working on an application that had to talk to a COBOL CISAM file to read and write data. We knew what we were doing as far as the data goes so this was not an issue. Well, there was a provider for doing this called USQL. It was not cheap however and the vendor was charging us in what is similar to the CAL based licensing in SQL sever (translation == ArmLeg). Needless to say when there were 18 companies hitting this USQL thing at any given time so we needed a LOT of licenses for it.
To get away from this we were going to write a singleton data service that handled requests to read and write data to this file. This singleton was going to use a COM component called “COBJects” (yeah I know it’s a cute name). Well – there was a problem with this - we needed a multithreaded singleton, and COBJects was not (according to the original programmer at that time) was not "Thread Safe".
Thread Safe… Now that is a term that immediately brings up bad memories of deadlocking issues in the COM and Win32 world that used to keep me up for hours *shudder*. But this used to be confusing to me – I cannot use a component in a multithreaded application because it is not “Thread Safe” – well why the hell NOT? I paid good money for it – I should be able to do with it as I wish!
Let’s try this on for size; what if I keep that component’s use within the context of a Mutex or Critical Section any given time I use it? Doesn’t that keep our component safe from multiple threads hitting it at once? If a thread grabs a Mutex and starts working with our Unthread Safe component then releases its resource handles to it before closing the Mutex – then only one thread is using that component, Right? Well… NO.
Here is where this old Theory Falls flat on its face. Let’s say this component has some static variables it uses to retain cached information internally – but this cached information is based on a state within the context of a given thread that uses it. Now another thread wants to play. Just as a simple example let’s say this component tracks some kind of Thread ID and the component uses it every time it goes out and <insert distributed task here> but only aquires it the first time the object gets created. Now the thread ID is wrong when it makes its call to the network in the context of the second thread. The server side stub gets the wrong value that it received from the client side proxy. Now we have PROBLEMS (and this is just an easy example). Debugging this can be the stuff of Nightmares that would make Freddy Kruger proud (if they made a Far Side Comic about this there would be a picture of this scenario with a bunch of guys scratching their heads with flames dancing around them in a red cave with the caption “Programmers Hell”).
However – there may be cases where this doesn’t happen – in which case you should be safe (single call type scenario – no statics used on the inside). But there are no guarantees in life and we will never know what goes on with the man behind the curtain (unless you are so bold as to throw the curtain back :) but this takes time – and when some other rich guy that doesn’t even get the concept of “Hello World” let alone this type of scenario – well – then we just have to assume the worst and move on so we can keep paying the rent.
So the moral to this story is this… If the component says it’s not thread safe. Then don’t hit the same instance of it with multiple threads. I learned quickly in my youth that my theory is wrong – and I hope that by telling it, I just kept any given n00bs to the world of multithreaded programming out of Programmer’s Hell.