Com within Thread

Hi,
I have declared the interface pointer as a class variable and called CoCreateInstance in thread of that class .

Is there any problem with this way ?

My COM object is based on aparment threading model.

My question is: I am using Single Threaded Apartment , will below mentioned code work ?

Example Code ( Don't go on syntax consider the logic )

Class CClient
{
public:
CClient();
~CClient();

Begin();
IMyInterface* pMyInterface ;
static UINT StartThread(LPVOID pParam);
}
CClient::CClient()
{
CoInitialize(NULL);
}

CClient::~CClient()
{
CoUninitialize(NULL);
}

CClient::Begin()
{
AfxBeginThread(StartThread,(LPVOID)this);
}
CClient::StartThread(LPVOID pParam)
{
CClient*pClient=(CClient*) pParam;
CoCreateInstance(CLSID_MyInterface, NULL,CLSCTX_ALL,
IID_IMyInterface, (void**)(IUnknown**) &pMyInterface );


}

The interface pointer will be valid in context of thread it has been got (i.e. in its apartment). Trying to use it in other thread (i.e. apartment) you'll get error.

Do not forget initialize apartment with CoInitialize().

You are right , I should have called CoInitialise() and CoUnitialise() in Thread function.


So According to you it's not possible to declare the Interface Pointer as a class variable and call CoCreateInstance in thread . right ?

Quote:

---

Originally Posted by navinkaus

So According to you it's not possible to declare the Interface Pointer as a class variable and call CoCreateInstance in thread . right ?

---

It's possible of course. But it would operate correctly only in one thread. I already explained why - interface pointers adhere their apartments, it doesn't matter what type of memory they reside in.

The class member is not worse or better choice, 'cause it's just a memory cell.

You might describe your task in more detailed manner - just to give us a chance to give you a better advice. :)

Quote:

---

Originally Posted by navinkaus

So According to you it's not possible to declare the Interface Pointer as a class variable and call CoCreateInstance in thread . right ?

---

It is of course possible. Why not?

One a side note, don't use raw interface pointers, use smart pointers like CComQIPtr, or CComPtr.

Like this -

Code:

---

Class CClient
{
public:
  // ...

  // Use smart pointer - CComQIPtr
  CComQIPtr <IMyInterface> pMyInterface ;
 
};

---

And usage...

Code:

---

CClient::StartThread(LPVOID pParam)
{
  CClient*pClient=(CClient*) pParam;
  CoInitialize (NULL);

  if (SUCCEEDED (pMyInterface.CoCreateInstance (CLSID_MyInterface)))
  {
        pMyInterface->SomeMethod ();

        // Done?
        pMyInterface.Release ();
  }
 
  ::CoUnintialize ();
}

---

As you can see, the smart pointer is easy to use, simple to read and has reduced the parameters for creating an instance from 5 to 1.

Siddhartha, here You went into the code where as I was looking to know something different, I know that there are various benefits of using Smart Pointers ( like allocation of memeory , release of memory etc ) .

But thing is that.

Due to a situation It is neccessary for me declaring the Interface Pointer as class variable and calling CoCreateInstance in Thread.

Now Point were :

1. Can I use methods of objects in both threads ?


Earlier Object was not behaving properly , After calling Coinitailize() and CoUnitialize() in thread also I am able to use the methods in main thread.

Since I am not good in COM threading Models so just wanted to know one simple question.


Is it possible to use object in the way which I mentioned in my code.

If still you are not able to understand the situation let me know , I will put this problem in altogther in a different way with real situation ( which is little long to specify ).

Quote:

---

Originally Posted by navinkaus

Now Point were :

1. Can I use methods of objects in both threads ?

---

Do not be confused with methods and objects. C++ objects and their methods can be used in multithreaded environment. But STA-adherent interface pointer must either be used in its own STA or (in case you intend to call its methods in another thread) it has to be marshalled to that thread.

In my practice I use simplified cross-thread marshalling in case my interface is used inside the same process.

Code:

---

class CSome
{
    . . .
    IMyInterface* m_pi;
    IStream*      m_stream;
    . . .
};

void CSome::Begin()
{
    if( !m_pi )
        CoCreateInstance( ... ); // here we create instance and get interface
    CoMarshalInterThreadInterfaceInStream( ... , &m_stream ); // here we immerse it into stream
    CreateTread( 0, 0, ThreadProc, this,... );
}

DWORD WINAPI ThreadProc(LPVOID lpv)
{
    IMyInterface* piLocal = NULL;
    CSome* pSome = (CSome*)pSome;
    CoInitialize();
    CoGetInterfaceAndReleaseStream(pSome->m_stream, ... , &piLocal); // here we get it emerged out already cooked
    // now! fire it
    piLocal->SomeMethod();
    . . .
}

---

Quote:

---

Originally Posted by navinkaus

Siddhartha, here You went into the code where as I was looking to know something different,

---

If you read my sample - you would see that it is answered therein.

Quote:

---

Originally Posted by navinkaus

Due to a situation It is neccessary for me declaring the Interface Pointer as class variable and calling CoCreateInstance in Thread.

---

Well... The situation is aviodable in every case.

Quote:

---

Originally Posted by navinkaus

1. Can I use methods of objects in both threads ?

---

Both? Yes, after initializing the COM Library in each as Igor already answered.

Quote:

---

Originally Posted by navinkaus

Is it possible to use object in the way which I mentioned in my code.

---

Yes... But note that when you do CoCreateInstance you create a new object... The interface pointer is simply pointing to it.

If one thread overwrites a valid interface pointer assigned aby another - you leak an object.

Quote:

---

Originally Posted by navinkaus

If still you are not able to understand the situation let me know , I will put this problem in altogther in a different way with real situation ( which is little long to specify ).

---

Real situation really helps... For one, I see no reason why you are using raw pointers... ;)

First of All, I am really very much thankful to both of you for providing your feedback on my questions ( might be stupid ) .

Now I tell you the real simulation.

Code:

---

Class  CTableObject
{
      public:
      IMyInterfacePtr pMyInterace;
      CTableObject(CString strTableName);
      ~CTableObject();
    EncryptDecryptTable();
   
};

CTableObject::CTableObject(CString strTableName)
{
    CoInitialize(NULL);
    pMyInterace.CreateInstance(__uuidof(MyInterface));
    /*
The reason of creating Interface Pointer as a member varialbe is , it's constructor takes too much time ( again buisness logic ) and since it is heavily used in the class so I declare it again and again it make this class too much slow that's I have declared it as a member variable */
    /*
 
  /// Logic goes here
}

CTableObject::EncryptDecryptTable()
{
    pMyInterace.EncryptDecrypt(/* Data */);
}

CTableObject::~CTableObject()
{
      CoUnitialize();
}


CClient
{
    public:   
    CTableObject  *pPrdouctTable,*pCustomerTable........10 objects;
    static UINT StartThread(LPVOID pParam);
    PerformSomeOperation();
};
 

CClient::StartThread(LPVOID pParam)
{
  Coinitialize(NULL );
  CClient*pClient=(CClient*) pParam;
    pClient->pTableObject= new CTableObject("Product");
    pClient->pCustomerTable= new CTableObject("Customers");
    Couninitialize();

}

CClient::PerformSomeOperation()
{
    pTableObject.EncryptDecryptTable();
}

---

Now Since My COM Class takes lot of time to create itself so it is obvious CTableObject Class will take now. There are lot of CTableObject objects so I put it in thread to initialize all CTableObject mean while user will get the dialog and can play with it ( on the background objects are being created ).

This is the real simulation ( flow ).

Whether I use raw interface pointer or smart pointers situation is same.

That is :

Interface is being created in one thread

and methods are called in different thread.

Let me know if you want to anything more .

All essential things on between-thread interface usage have already been said. You have to marshal iterface pointer to use it out of its STA. The choice of the way you do it is left on your own.

Interface marshalling could affect whole performance because of method parameters data marshalling.

Maybe more appropriate solution might look like you create all working interfaces in main thread, but you run that for-a-while-dialog-to-play-with in a separate thread.

But one strange thing, Without doing marshalling , It is working...If you want I could send you the sample code.

Quite Strange na ........

I just put the Coinitialize() in the thread also.

Yes... That shouldn't really be a problem.

I haven't yet seen a case where interface pointers used across thread boundaries (with COM initialized in the threads) don't work unless marshalling is done.

AFAIS, it is a non-issue.

Siddhartha, so do you mean without marshalling it will work ?

Thanks both of you for sharing your views.

Also I got a very useful link which describes things some of them which we have already covered , but would like to share with you.

http://msdn.microsoft.com/library/de...57fd794809.asp

Also I am doing some R & D on this so we will get back to you as soon as I get something more interesting.

The link is really very good , it answers all the question of mine but I didn't understand one thing.

" To handle calls from other processes and apartments within the same process, each single-threaded apartment must have a message loop. This means that the thread's work function must have a GetMessage/DispatchMessage loop. If other synchronization primitives are being used to communicate between threads, the Win32 function MsgWaitForMultipleObjects can be used to wait both for messages and for thread synchronization events. The Platform SDK documentation for this function has an example of this sort of combination loop."

Do I need message loop in my thread ? and why ?

Quote:

---

Originally Posted by navinkaus

Siddhartha, so do you mean without marshalling it will work ?

---

I mean that I have never seen it not work when interface pointers are not marshalled across threads - so long as the thread initializes COM using CoInitialize before using the same, things work fine.

You will need the message loop, when you marshal the interface pointer, and then unmarshal and use it in a different thread. This is because the proxy and stub communicate via windows messages.

If you dont marshal / unmarshal the interface pointer, it may or may not work across appartments - but you loose the synchronization which com provides for components in STAs.

Prosise has published 2 really nice articles on code guru, which should probably explain things clearly
http://www.codeguru.com/Cpp/COM-Tech...cle.php/c5529/
and
http://www.codeguru.com/Cpp/COM-Tech...cle.php/c5533/

Thanks alot!!!!!!!!!!!! you closed my all remaining queries.

Quote:

---

Originally Posted by navinkaus

Thanks alot!!!!!!!!!!!! you closed my all remaining queries.

---

You are welcome... ;)

hey.....got some new questions...but think these are stupid questions they are very much good questions I found on google earlier I was thinking that I am putting stupid questions. anyways my questions are:


1. At what point I need to put message loop if my code looks like this in thread

object->Method1
object->Method2
object->Method3


I think I need to put the message loop in end.


2. Since I know that at a time only one thread will use the com object still I need to do marashalling and use message loop.

Here are the result of my R & D.

1. Without Marashalling

If you don't use Marashalling there is no problem in my sample application.
It does not give you gurantee of serialization. it can call methods either first in main thread or in child thread. In other words order of calling method is not fixed ( serialised )

Even you can use WaitForSingleObject for serialisation.



2. With Marashalling

It gives you gurantee of serialisation.

You can not use WaitForSingleObject ( otherwise it will be in deadock )

Here interesting thing is: In my case whether I use message loop or not does not effect at all.


This is my R & D till now. You comments will be highly appreciated.

Now I tell you what I concluded. There is no benefit of thread in case of STA.

As in case of STA , you need marashalling to use the object across the threads, and you calls get serialized.

Now since your calls get serialized your main thread stucks till your child thread ends processing. So my user will not see the dialog so in this case it is better not to use the thread.


Now the answer of milliion dollar question, "I worte previously that it works without using marashalling" This is incorrect as sometimes difficult to re-produce you stuck in thread forever.

So across the threads you need to use marashallling with message loop.


In summary, there is no benefit of using thread in case of STA

Quote:

---

Originally Posted by navinkaus

In summary, there is no benefit of using thread in case of STA

---

Please do note - you forgot to add 'In my case'. :)
There are many COM components with STA, which use threads with no troubles. The matter of experience/understanding/suitability/design/etc.