Most programmers write in-proc COM servers using the apartment threading model, also known as the single-threaded apartment model. See Chapter 13 of my book The Essence of COM with ActiveX, or my article in the February 1997 Microsoft Systems Journal for a further explanation of that model. Basically a client promises COM that it will call an object’s methods only from the thread on which it created the object, and the object's server promises COM that it knows how to live in that kind of environment. Since both parties agree on the rules, COM provides them with a direct, unmarshaled connection instead of a proxy/stub connection, essentially allowing them to have unprotected sex. The objects generally don't protect themselves against concurrent access from multiple threads, since the client has promised not to do this.

Major problems can arise if an object’s client doesn’t keep that promise. "Sure, cutie object, I’ll still respect you in the morning. And only one thread at a time. Are you going to believe the President of These Here United States or your lying eyes?" Suppose a client app's calls CoCreateInstance( ) from Thread A to create an apartment threaded object, puts the object’s interface pointer in a global variable, and then Thread B makes a call into that object. The object hasn't protected its instance data against calls from different threads because the apartment threading model says that it shouldn't have to. All kinds of terrible things can happen. If you’re lucky, you’ll crash right away. But more often, this leads to the worst kind of bugs – subtle, flaky, and impossible to reproduce. And even though it’s the client app’s fault for not following the rules, it’s YOUR tech support line that gets the nasty phone calls and the bomb threats. You’d better hope that you haven’t sold any to the postal service.

As you no doubt tell (or will tell) your daughters, your object needs to protect itself against a dishonest client. You could serialize access to all your member variables, even though the rules of the apartment threading model say that in an ideal world you shouldn't have to. But this is difficult and expensive to write in C++ and impossible in Visual Basic. It's actually quite easy in Visual Java, but the legal wrangles currently going on over Java are causing many of my clients to stay away from it for now. Components written in Java are somewhat slow anyway.

The easiest solution is for your object to check at the beginning of each method call whether the client made the call from the proper thread. It's sort of like performing an instantaneous virus test on your date before actually doing anything. If you come up with a real-life way of doing this, you can leave the geek business and open your own bank.

It's fairly simple to set this up. The operating system assigns each thread a DWORD identifier called the thread ID, which is guaranteed to be unique on your machine. In your object's constructor, you call the API function GetCurrentThreadId( ), which will return the ID of the thread from which it is called, the thread on which the object is being created. You store this thread ID in a member variable of your object. Then whenever your object receives a call, you call GetCurrentThreadId( ) again and compare the result to the one you first got in your constructor. If they match, then you were called from the right thread and everything is cool. If not, you return immediately with an informative error code, before doing anything in your object that might get messed up. You'd really like to strangle the client, but this is a little hard to program. You could pop up a message box that says you've caught him, and the next time it happens, you'll format his hard drive.

The only difficulty in implementing the thread ID check is forcing your programmers to do it every time. [Note: in the last issue, I compared managing programmers to herding cats. A reader named Robin wrote in to say that she has no trouble whatsoever herding her three cats -- just open a can of tuna fish, hold it at knee level, and start walking. What would you use for programmers? Latte? More RAM? Stock options?] Embedding it into macros that you insist programmers use in every class and method seems to be the most dependable way.  It's easy to change the code on a project-wide basis if it causes trouble or if you need to add something. You can combine the thread check code with other macro code like the reference counting example I discussed in the previous issue of Thunderclap. I've seen this technique used at Microsoft and Dragon Systems, among other companies. Once you've decided to use it, the problem then becomes making sure it happens every time. The approach I'll show uses the macro idea I got from Dragon Systems, as discussed in the previous issue of ThunderClap.

You define three macros, thus:

You put the first in an object's class declaration, thus:

You put the second in the object's constructor, thus:

You use the third at the start of every method, thus:

B) Protecting Against Synchronization Deadlocks in the Free or Both Threading Models

The second problem I'll discuss in this newsletter is the problem of synchronization deadlocks in the multi-threaded apartment. If you're using the free threaded model (or both threading models), don't make an outgoing COM call while you are holding a lock. You could wind up tying yourself into a five-dimensional hyperpretzel. Here's the problem. Consider the following code, made to execute in a multi-threaded apartment:

What could be simpler ? It's classic Win32 multithreaded programming, what could possibly be wrong with it? The problem is that, since COM uses proxies and stubs to marshal calls between apartments, processes, and machines, that the thread you are running on at any given time isn't necessarily the one you think you are running on. The logical thread doesn't always match the physical thread.

The client calls a method on the object [stop me if I get too technical ;-)]. Since the call goes out through a proxy, it originates on Thread 1 and is actually received by the object on Thread 2. The object calls EnterCriticalSection on Thread 2. Now suppose that within the function DoSomeWorkRequiringSerialization( ) the object makes an outgoing call back to the client, for example an event notification. This is pure classic COM, nothing fancy or pushing the envelope. The call leaves the object on Thread 2, goes through proxy and stub and is received by the client's callback interface on Thread 3. Now suppose the client, within the callback method, calls the first method on the object again, or for that matter, any method that uses the same critical section. The call goes out on Thread 3, through the proxy and stub and is received by the object on Thread 4. When the object calls EnterCriticalSection from Thread 4, the call will block because the critical section is owned by Thread 2. And because critical sections don't support timeouts, it will hang forever.

If the second call had come into the object on Thread 2, there would have been no problem. Calling EnterCriticalSection would have succeeded, because the serialization mechanism knows which thread owns it and will detect and allow reentry. However, in this case, it didn't and we're hung. Even though the calls proceeded in a logical sequence (on the same "logical thread"), because of the intermediation of the proxy and stub, the second call actually came in on a different physical thread, and it is the physical thread that all the Win32 operating system synchronization objects use to detect and allow reentry.

This problem is potentially quite bad. Think how you'd feel if you spent five hours writing a document and then got hung before you could save. Hoping it doesn't bite you isn't exactly the gold standard of software robustness. The software industry is remarkably free of professional liability suits, compared to, for example, the medical industry; but it's this kind of crap that could get the lawyers smelling blood.

So what can we do about this? You have a couple of choices, none of them great. If DoSomeWorkRequiringSerialization( ) hadn't made a call out to the original client, which in turn called back into the object, then the deadlock wouldn't have happened. So it looks like we might be safe if we didn't call back into the original client. But this isn't reliable because you don't know how ANY COM object is implemented internally. Even if you called not back into the client but rather into some other COM object, how do you know that this object doesn't call back into the original client (or into another object that does, or into another object that does, etc…) ? You can't and you don't unless you wrote them all. The only absolutely safe thing to do here is not to make any calls to any COM objects while you hold a serialization lock. You'd have to write the code something like this:

}

It looks like hell and it's not far off, especially since the utility functions you call (and the functions they call, and the functions they call, etc. ...) must not make any outgoing COM calls. The difficulty of writing code of this sort is one of the reasons why developers stay away from these threading models. Got any other ideas?

If you think you will encounter this problem rarely, you could try to detect it and fail the call instead of allowing the deadlock. It's fairly easy to do with a mutex and a timeout. The code would look something like this:

It's extremely ugly. It reminds me of one system that I built many years ago that I just could not keep from crashing occasionally, at which time it had to be rebooted. I put a watchdog timer card on the bus the would reboot the system if the program didn't write to a certain port every few minutes. For $100 per box, I met the design specs for unattended uptime. But like that solution, it's quick and cheap to write and at least you won't get tied into yogic knots. The primary difficulty here is determining the appropriate timeout interval to use while waiting on the mutex. Make it too short and legal calls coming from other threads will time out and fail, while waiting for another thread that would actually return. Make it too long and the user will lose patience and press 'Reset'. You really only want to do this if you think you'll see the problem very rarely and just want to be safe.

As W. C. Fields used to say, "If at first you don't succeed, try, try again. Then quit. There's no sense being a damn fool about it." The easiest solution to this problem would be to bail out and use the apartment model instead. The components are much easier to write, and if your clients are also apartment threaded, they'll run faster than free threaded components. Ask yourself why you are using the free threaded model in the first place. If it's just to be a stud, try banging your head against the wall, it's less painful and about as rewarding.

This entire problem will go away if you switch to Visual Java. Components written in VJ automatically support both threading models. Providing serialization of your Java methods is as simple as adding the keyword "synchronized" to the method definition in your class file, like this:

public synchronized void SayHello ( )
{
    MessageBox (0, HelloMessage, "jhellodll", 0) ;
}

It doesn't get a whole lot easier, but many developers aren't ready to make the jump to Java yet. Maybe they will when they have to start writing free-threaded code. Visual Java is a whole lot better than Visual Basic. A C++ geek could honorably switch to Java.

In the final analysis, synchronization of this type is a generic problem. It would be ideal if we could inherit a generic solution from the operating system, as we have to so many other problems. And that's coming. COM+ is adding synchronization to the array of services that any component can inherit from the runtime environment, if it converts to the COM+ religion. I'd like to write about that in the next issue of this newsletter. My NDA and Microsoft's schedule might or might not let me do it. Watch this space for that, or something else cool.