Issues with static members/methods in COM/ATL? 
Author Message
 Issues with static members/methods in COM/ATL?

I have an in-process COM object written using ATL in Visual C++.  I'd like
to keep a static list of instances so that I could broadcast infromation to
all of them from one static method call.

What issues do I have to deal with then?  For instance, how would I call a
static method in such a class without first instantiating an object?  And
secondly, what sort of threading issues should I worry about?

--
-----------------------------------------------------
Brian J. Sayatovic



Fri, 02 May 2003 03:00:00 GMT  
 Issues with static members/methods in COM/ATL?


Quote:

> I have an in-process COM object written using ATL in Visual C++.  I'd like
> to keep a static list of instances so that I could broadcast infromation
to
> all of them from one static method call.

Change your COM Server to out-of-process first. Then create your
"instance-communication" class (it MUST be thread-safe !) . You may
instantiate it in two ways:
- static variable in program body. Constructor will not have access to
hInstance (and thus some API functions & ATL classes)!
- static pointer to variable and static handle to semaphore in program body.
You may fill the pointer in _tWinMain , or in CoExeClass (if you decide to
change it's Init(...) and Term() implementation). Of course somemaphore is
necessary to count threads and release memory when last thread is exiting.

Quote:
> What issues do I have to deal with then?  For instance, how would I call a
> static method in such a class without first instantiating an object?  And

I forgot to link my COM Server to multithreading library, and I got in
result all kind of run-time exceptions. So this is one thing to remember ;)
Another: if you want  your threads to exchange interfaces, make them all
work in the same apartment (just define _ATL_FREE_THREADED instead of
_ATL_APARTMENT_THREADED ) Do not forget that each thread has to call
CoInitializeEx and CoUninitialize (it's inside _tWinMain, but if you create
your own "worker" thread, you need to do it by yourself)

Rgds

B.



Fri, 02 May 2003 03:00:00 GMT  
 Issues with static members/methods in COM/ATL?

Are you saying to use an out-of-process COM object because if it were
in-process, each process would have its own classinstance, and thus,
different static members?

That would truly be a problem.  However, what do I give up by leaving the
in-process model?  I was under the impression that in my case, imlementing a
BHO, it needs to be an in-process object.

--
-----------------------------------------------------
Brian J. Sayatovic


Quote:


> > I have an in-process COM object written using ATL in Visual C++.  I'd
like
> > to keep a static list of instances so that I could broadcast infromation
> to
> > all of them from one static method call.

> Change your COM Server to out-of-process first. Then create your
> "instance-communication" class (it MUST be thread-safe !) . You may
> instantiate it in two ways:
> - static variable in program body. Constructor will not have access to
> hInstance (and thus some API functions & ATL classes)!
> - static pointer to variable and static handle to semaphore in program
body.
> You may fill the pointer in _tWinMain , or in CoExeClass (if you decide to
> change it's Init(...) and Term() implementation). Of course somemaphore is
> necessary to count threads and release memory when last thread is exiting.

> > What issues do I have to deal with then?  For instance, how would I call
a
> > static method in such a class without first instantiating an object?
And

> I forgot to link my COM Server to multithreading library, and I got in
> result all kind of run-time exceptions. So this is one thing to remember
;)
> Another: if you want  your threads to exchange interfaces, make them all
> work in the same apartment (just define _ATL_FREE_THREADED instead of
> _ATL_APARTMENT_THREADED ) Do not forget that each thread has to call
> CoInitializeEx and CoUninitialize (it's inside _tWinMain, but if you
create
> your own "worker" thread, you need to do it by yourself)

> Rgds

> B.



Fri, 02 May 2003 03:00:00 GMT  
 Issues with static members/methods in COM/ATL?



Quote:

> Are you saying to use an out-of-process COM object because if it were
> in-process, each process would have its own classinstance, and thus,
> different static members?

Yes. One way to share common data between class instances is to share them
in process of common COM server - that is out-of-process that has been
registered for multiple use. Other way would be to create system service (or
other kind of local server) allowing other processes to share the same data
(through file mapping, named pipes or some other means).

If you need to share data between in-process COM servers, you may try to use
something similar to:

CommonDataServer(void *)
{
    HANDLE hFile = CreateFileMapping(INVALID_HANDLE_VALUE, NULL,
PAGE_READWRITE, MAX_SIZE_HIGH, MAX_SIZE_LOW, "MyAppMappedFile");

    // ... some synchronization to keep our function running as long as we
need it
    // ...

    CloseHandle(hFile);

Quote:
}

HANDLE hFile = NULL;
LPVOID lpData = NULL;
HANDLE hSem = CreateSemaphore(NULL, MAX_THREADS, MAX_THREADS,
"Global\MyAppSemaphore");

if (hSem != NULL)
{
    // ok, we have access to common data
    if (GetLastError() != ERROR_ALREADY_EXISTS)
    {
        // we are first to use this semaphore - thus we need to initialize
mapped file
        CreateThread (NULL,NULL,CommonDataServer,(void *) &lock,0,NULL);
        Sleep(20);
    }

    hFile = OpenFileMapping(FILE_MAP_ALL_ACCESS,FALSE,"MyAppMappedFile");
    lpData = MapViewOfFile (hFile,FILE_MAP_ALL_ACESS,0,0,0);

    // ... here you can use common data

    UnmapViewOfFile(lpData);
    CloseHandle(hFile);

    ReleaseSemaphore(hSem,1,NULL);

Quote:
}

... BUT if first COM client process exits, CommonDataServer(void *) will be
terminated also. You will lose access to common data, and next COM server
instances will need to re-create it - so the code above if far incomplete.

Quote:
> That would truly be a problem.  However, what do I give up by leaving the
> in-process model?  I was under the impression that in my case, imlementing
a
> BHO, it needs to be an in-process object.

You may easilly implement both: create very simple in-process COM object
with the basic functionality you need, which will in turn call other,
out-of-process object (use #import  "... .tlb" directive in your in-process
COM server to make it simple). There are special considerations when passing
interfaces between apartments.

Regards

B.



Sat, 03 May 2003 03:00:00 GMT  
 Issues with static members/methods in COM/ATL?

-- below...

--
Reginald Blue                   | Opinions expressed here do not
Natural Language Understanding  | necessarily represent those of
Unisys Corporation              | my employer.
--------------------------------+-------------------------------

NL technology,speech application| My email address is wrong, you
development training, see:      | need to remove the obvious.
http://www.speechdepot.com/     +-------------------------------



Quote:
> For instance, how would I call a
> static method in such a class without first instantiating an object?

-- In addition to all that Bronek has stated, the answer to this one is
quite simple.  Given a class CFoo and a static method MyStatic which takes
no parameters, one may call it w/o instantiating the class as:

CFoo::MyStatic();

-- HTH



Sat, 03 May 2003 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. ATL COM - Passing ATL COM classes through another ATL COM class in the same app

2. COM/ATL novice:passing object pointers through methods on a COM interface

3. Static member threading issue

4. Clas Methods (static member functions)

5. Possible circular dependency issue between ATL COM services

6. Design/performance Issue in ATL COM

7. ATL Actives Server COM secuity issue !!!

8. Static members and COM DLL

9. Static callback method & ATL

10. Cant use VC ATL COM DLL method at VB project

11. Howto Expose a normal C++ class with methods via an Interface Class in ATL COM

12. how to call function in a DLL from ATL COM method

 

 
Powered by phpBB® Forum Software