Threading Revisited

[Previous] [Next]

After a careful examination of the implementation of the TipOfTheDay coclass, we confirmed our original suspicions: we were able to design the component such that it doesn't store global data, per-class data, or even per-instance data. The state of the component is entirely determined by the cookie parameter stored by the client application, so restricting object access to a single thread is unnecessary. Because the TipOfTheDay component doesn't use worker threads, there's no reason we wouldn't allow it to be created in an STA, so it makes sense to support both threading models. We'll change the Registry setting from ThreadingModel=Apartment to ThreadingModel=Both by editing the TIPOFTHEDAY.RGS file that the ATL Object Wizard created and added to the project.

 InprocServer32 = s `%MODULE%' {     val ThreadingModel = s `Both' } 

We'll also need to change some wizard-generated code to reflect the threading model. Replace

 #define _ATL_APARTMENT_THREADED Public CComObjectRootEx<CComSingleThreadModel> 

with

 #define _ATL_FREE_THREADED Public CComObjectRootEx<CComMultiThreadModel> 

NOTE

---

It wouldn't be accurate to say that the TipOfTheDay component is stateless, because the call history does indeed affect the data returned by the GetNextTip method. A client that calls GetNextTip three times will get a different result than a client that calls GetNextTip four times. More precisely, our component can be called "state estranged." A separate entity manages and stores its state.