Threading model for the client application 
Author Message
 Threading model for the client application

Hi all,

I have some doubts about the type of threading model i
should choose for my client application which is accessing
the MTA COM server.
I am using ATL 3.0 for the COM server development and MFC
gui as the client.

My concerns are the following

1) Can i create the MFC gui client main thread to join the STA.
2) Is there any problem in receving multiple callbacks
fired from the MTA COM server in the MFC gui, if i create
my GUI in STA?.
3)Is there any advantage if i create the gui client sink
interface alone in MTA to receive the callbacks keeping
the GUI main thread in STA.
4)If i create gui main thread in STA, can i make other
threads created in the gui to join MTA( just to save time
in marshalling the interface pointers between apartments)

Hope some body can give me valid suggestions to save me.

Thanks & Regards
Karinta(ABG)



Sun, 23 May 2004 16:35:11 GMT  
 Threading model for the client application

Quote:
> Hi all,

> I have some doubts about the type of threading model i
> should choose for my client application which is accessing
> the MTA COM server.
> I am using ATL 3.0 for the COM server development and MFC
> gui as the client.

> My concerns are the following

> 1) Can i create the MFC gui client main thread to join the STA.

You pretty much have to. GUI is thread-affine, it does not work well in MTA.

Quote:
> 2) Is there any problem in receving multiple callbacks
> fired from the MTA COM server in the MFC gui, if i create
> my GUI in STA?.

No problem, except that callbacks will be serialized, so that if two server
threads call a callback at the same time, they need to wait until the client
processes the first callback, then the second one.

Quote:
> 3)Is there any advantage if i create the gui client sink
> interface alone in MTA to receive the callbacks keeping
> the GUI main thread in STA.

Some people do that in order not to slow down the server. You spin an MTA
thread and advise your sinks from there. When the event arrives, the sink
needs to notify the main thread somehow (usually by posting a message) and
returns immediately.

Quote:
> 4)If i create gui main thread in STA, can i make other
> threads created in the gui to join MTA( just to save time
> in marshalling the interface pointers between apartments)

You can create MTA worker threads, but it is real pain to do any GUI in MTA.
Non-GUI components can be created in MTA just fine.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat, and
wrong." H.L. Mencken



Mon, 24 May 2004 01:12:17 GMT  
 Threading model for the client application
Thanks Igor Tandetnik for your early reply.
I have one more question .

As you explained i have created a new MTA in my GUI and
created my gui client sink interface there. The code is
given below.

//The thread MultithreadMode is created from  
//CWinApp::InitInstance method, so that the MTA is active
//as soon as the GUI is up and running

unsigned __stdcall MultithreadMode(LPVOID pThis)
{
        CoInitializeEx(NULL, COINIT_MULTITHREADED);

//CSEMIStdGUIApp is my MFC CWinApp derived Class
        CSEMIStdGUIApp* pThisObject =
reinterpret_cast<CSEMIStdGUIApp*>(pThis);

// The following method creates the sink and
// advises my MTA COM server

        pThisObject->GUIAdvise();
        while(1)
        {

                Sleep(100);

        }
     CoUninitialize();          
     return 1;

Quote:
}

Do you think is there any problem in making my MTA thread
alive my putting a while loop. (Later i am planning to
modify the above while loop by using an Event object as
the loop exit condition, so that this MTA thread dies when
my GUI main thread exits.)

For me the above the Advise method from the GUI MTA thread
works, But i have noticed that there is a significant
delay in receiving the callbacks when i do the above
method of advising the server from the MTA thread when
compared to the advise i do from the STA(normal case).

Even if i create this MTA to advise the sink, do you think
is there any real perfomance benefits for me when compared
to the advise the COM server from the STA??, because in
both the cases we need to post the message to the main
thread when we receive the callbacks from the MTA COM
server.

Your advice is highly appreciated.
Thanks & Regards
Karinta.(BAG)

Quote:
>-----Original Message-----


>> Hi all,

>> I have some doubts about the type of threading model i
>> should choose for my client application which is
accessing
>> the MTA COM server.
>> I am using ATL 3.0 for the COM server development and
MFC
>> gui as the client.

>> My concerns are the following

>> 1) Can i create the MFC gui client main thread to join
the STA.

>You pretty much have to. GUI is thread-affine, it does

not work well in MTA.
Quote:

>> 2) Is there any problem in receving multiple callbacks
>> fired from the MTA COM server in the MFC gui, if i
create
>> my GUI in STA?.

>No problem, except that callbacks will be serialized, so
that if two server
>threads call a callback at the same time, they need to

wait until the client
Quote:
>processes the first callback, then the second one.

>> 3)Is there any advantage if i create the gui client sink
>> interface alone in MTA to receive the callbacks keeping
>> the GUI main thread in STA.

>Some people do that in order not to slow down the server.
You spin an MTA
>thread and advise your sinks from there. When the event
arrives, the sink
>needs to notify the main thread somehow (usually by

posting a message) and

- Show quoted text -

Quote:
>returns immediately.

>> 4)If i create gui main thread in STA, can i make other
>> threads created in the gui to join MTA( just to save
time
>> in marshalling the interface pointers between
apartments)

>You can create MTA worker threads, but it is real pain to
do any GUI in MTA.
>Non-GUI components can be created in MTA just fine.
>--
>With best wishes,
>    Igor Tandetnik

>"For every complex problem, there is a solution that is
simple, neat, and
>wrong." H.L. Mencken

>.



Mon, 24 May 2004 02:36:26 GMT  
 Threading model for the client application
Have your marshaled interface pointers from STA to MTA thread? You need to.

Is the MTA server in-proc or out-of-proc? What exactly is the delay - ms,
seconds, minutes? Is it between server firing and MTA thread receiving, or
between MTA thread receiving and the GUI updating?

You'd better switch your MTA thread to waiting on an event. It eats CPU
cycles unnecessarily.

There is no benefit to the client in sinking events from dedicated MTA
thread. If anything, it is more work. However, it helps the server scale
better. If all events are getting fired to the same STA thread, firing
events becomes a synchronization point in the server - the same as requiring
every thread to enter a global critical section at this point.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat, and
wrong." H.L. Mencken


Quote:
> Thanks Igor Tandetnik for your early reply.
> I have one more question .

> As you explained i have created a new MTA in my GUI and
> created my gui client sink interface there. The code is
> given below.

> //The thread MultithreadMode is created from
> //CWinApp::InitInstance method, so that the MTA is active
> //as soon as the GUI is up and running

> unsigned __stdcall MultithreadMode(LPVOID pThis)
> {
> CoInitializeEx(NULL, COINIT_MULTITHREADED);

> //CSEMIStdGUIApp is my MFC CWinApp derived Class
> CSEMIStdGUIApp* pThisObject =
> reinterpret_cast<CSEMIStdGUIApp*>(pThis);

> // The following method creates the sink and
> // advises my MTA COM server

> pThisObject->GUIAdvise();
> while(1)
> {

> Sleep(100);

> }
>      CoUninitialize();
>      return 1;
> }

> Do you think is there any problem in making my MTA thread
> alive my putting a while loop. (Later i am planning to
> modify the above while loop by using an Event object as
> the loop exit condition, so that this MTA thread dies when
> my GUI main thread exits.)

> For me the above the Advise method from the GUI MTA thread
> works, But i have noticed that there is a significant
> delay in receiving the callbacks when i do the above
> method of advising the server from the MTA thread when
> compared to the advise i do from the STA(normal case).

> Even if i create this MTA to advise the sink, do you think
> is there any real perfomance benefits for me when compared
> to the advise the COM server from the STA??, because in
> both the cases we need to post the message to the main
> thread when we receive the callbacks from the MTA COM
> server.

> Your advice is highly appreciated.
> Thanks & Regards
> Karinta.(BAG)

> >-----Original Message-----


> >> Hi all,

> >> I have some doubts about the type of threading model i
> >> should choose for my client application which is
> accessing
> >> the MTA COM server.
> >> I am using ATL 3.0 for the COM server development and
> MFC
> >> gui as the client.

> >> My concerns are the following

> >> 1) Can i create the MFC gui client main thread to join
> the STA.

> >You pretty much have to. GUI is thread-affine, it does
> not work well in MTA.

> >> 2) Is there any problem in receving multiple callbacks
> >> fired from the MTA COM server in the MFC gui, if i
> create
> >> my GUI in STA?.

> >No problem, except that callbacks will be serialized, so
> that if two server
> >threads call a callback at the same time, they need to
> wait until the client
> >processes the first callback, then the second one.

> >> 3)Is there any advantage if i create the gui client sink
> >> interface alone in MTA to receive the callbacks keeping
> >> the GUI main thread in STA.

> >Some people do that in order not to slow down the server.
> You spin an MTA
> >thread and advise your sinks from there. When the event
> arrives, the sink
> >needs to notify the main thread somehow (usually by
> posting a message) and
> >returns immediately.

> >> 4)If i create gui main thread in STA, can i make other
> >> threads created in the gui to join MTA( just to save
> time
> >> in marshalling the interface pointers between
> apartments)

> >You can create MTA worker threads, but it is real pain to
> do any GUI in MTA.
> >Non-GUI components can be created in MTA just fine.
> >--
> >With best wishes,
> >    Igor Tandetnik

> >"For every complex problem, there is a solution that is
> simple, neat, and
> >wrong." H.L. Mencken

> >.



Mon, 24 May 2004 04:34:18 GMT  
 Threading model for the client application
Well... a well written server fires its events from a dedicated thread.
There's no need to go through that much pain in the client too.,,
(unless the server is not a well written one)

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD

MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================


Quote:
> Have your marshaled interface pointers from STA to MTA thread? You need
to.

> Is the MTA server in-proc or out-of-proc? What exactly is the delay - ms,
> seconds, minutes? Is it between server firing and MTA thread receiving, or
> between MTA thread receiving and the GUI updating?

> You'd better switch your MTA thread to waiting on an event. It eats CPU
> cycles unnecessarily.

> There is no benefit to the client in sinking events from dedicated MTA
> thread. If anything, it is more work. However, it helps the server scale
> better. If all events are getting fired to the same STA thread, firing
> events becomes a synchronization point in the server - the same as
requiring
> every thread to enter a global critical section at this point.
> --
> With best wishes,
>     Igor Tandetnik

> "For every complex problem, there is a solution that is simple, neat, and
> wrong." H.L. Mencken



> > Thanks Igor Tandetnik for your early reply.
> > I have one more question .

> > As you explained i have created a new MTA in my GUI and
> > created my gui client sink interface there. The code is
> > given below.

> > //The thread MultithreadMode is created from
> > //CWinApp::InitInstance method, so that the MTA is active
> > //as soon as the GUI is up and running

> > unsigned __stdcall MultithreadMode(LPVOID pThis)
> > {
> > CoInitializeEx(NULL, COINIT_MULTITHREADED);

> > //CSEMIStdGUIApp is my MFC CWinApp derived Class
> > CSEMIStdGUIApp* pThisObject =
> > reinterpret_cast<CSEMIStdGUIApp*>(pThis);

> > // The following method creates the sink and
> > // advises my MTA COM server

> > pThisObject->GUIAdvise();
> > while(1)
> > {

> > Sleep(100);

> > }
> >      CoUninitialize();
> >      return 1;
> > }

> > Do you think is there any problem in making my MTA thread
> > alive my putting a while loop. (Later i am planning to
> > modify the above while loop by using an Event object as
> > the loop exit condition, so that this MTA thread dies when
> > my GUI main thread exits.)

> > For me the above the Advise method from the GUI MTA thread
> > works, But i have noticed that there is a significant
> > delay in receiving the callbacks when i do the above
> > method of advising the server from the MTA thread when
> > compared to the advise i do from the STA(normal case).

> > Even if i create this MTA to advise the sink, do you think
> > is there any real perfomance benefits for me when compared
> > to the advise the COM server from the STA??, because in
> > both the cases we need to post the message to the main
> > thread when we receive the callbacks from the MTA COM
> > server.

> > Your advice is highly appreciated.
> > Thanks & Regards
> > Karinta.(BAG)

> > >-----Original Message-----


> > >> Hi all,

> > >> I have some doubts about the type of threading model i
> > >> should choose for my client application which is
> > accessing
> > >> the MTA COM server.
> > >> I am using ATL 3.0 for the COM server development and
> > MFC
> > >> gui as the client.

> > >> My concerns are the following

> > >> 1) Can i create the MFC gui client main thread to join
> > the STA.

> > >You pretty much have to. GUI is thread-affine, it does
> > not work well in MTA.

> > >> 2) Is there any problem in receving multiple callbacks
> > >> fired from the MTA COM server in the MFC gui, if i
> > create
> > >> my GUI in STA?.

> > >No problem, except that callbacks will be serialized, so
> > that if two server
> > >threads call a callback at the same time, they need to
> > wait until the client
> > >processes the first callback, then the second one.

> > >> 3)Is there any advantage if i create the gui client sink
> > >> interface alone in MTA to receive the callbacks keeping
> > >> the GUI main thread in STA.

> > >Some people do that in order not to slow down the server.
> > You spin an MTA
> > >thread and advise your sinks from there. When the event
> > arrives, the sink
> > >needs to notify the main thread somehow (usually by
> > posting a message) and
> > >returns immediately.

> > >> 4)If i create gui main thread in STA, can i make other
> > >> threads created in the gui to join MTA( just to save
> > time
> > >> in marshalling the interface pointers between
> > apartments)

> > >You can create MTA worker threads, but it is real pain to
> > do any GUI in MTA.
> > >Non-GUI components can be created in MTA just fine.
> > >--
> > >With best wishes,
> > >    Igor Tandetnik

> > >"For every complex problem, there is a solution that is
> > simple, neat, and
> > >wrong." H.L. Mencken

> > >.



Mon, 24 May 2004 07:28:17 GMT  
 Threading model for the client application
Hi Igor Tandetnik

Quote:
>>>Have your marshaled interface pointers from STA to MTA
>>>>thread? You need to.

 i also marshal the interface between my STA and the MTA
thread.

I am still investigating why the delay is happening when i
get callbacks in a MTA created sink interface and where is
the source of the delay.

BTW: Do you think is there any problem if i use
Sendmessage to send the message to my GUI thread from my
callback sink method. Does this block any pending
callbacks? (Here the question is with respect to the GUI
thread running in STA and no MTA to recieve the callbacks).

I will getback to you with my test results.
Regards,
Karinta.

Quote:
>-----Original Message-----
>Have your marshaled interface pointers from STA to MTA

thread? You need to.
Quote:

>Is the MTA server in-proc or out-of-proc? What exactly is
the delay - ms,
>seconds, minutes? Is it between server firing and MTA

thread receiving, or
Quote:
>between MTA thread receiving and the GUI updating?

>You'd better switch your MTA thread to waiting on an
event. It eats CPU
>cycles unnecessarily.

>There is no benefit to the client in sinking events from
dedicated MTA
>thread. If anything, it is more work. However, it helps
the server scale
>better. If all events are getting fired to the same STA
thread, firing
>events becomes a synchronization point in the server -

the same as requiring
Quote:
>every thread to enter a global critical section at this
point.
>--
>With best wishes,
>    Igor Tandetnik

>"For every complex problem, there is a solution that is
simple, neat, and
>wrong." H.L. Mencken



>> Thanks Igor Tandetnik for your early reply.
>> I have one more question .

>> As you explained i have created a new MTA in my GUI and
>> created my gui client sink interface there. The code is
>> given below.

>> //The thread MultithreadMode is created from
>> //CWinApp::InitInstance method, so that the MTA is
active
>> //as soon as the GUI is up and running

>> unsigned __stdcall MultithreadMode(LPVOID pThis)
>> {
>> CoInitializeEx(NULL, COINIT_MULTITHREADED);

>> //CSEMIStdGUIApp is my MFC CWinApp derived Class
>> CSEMIStdGUIApp* pThisObject =
>> reinterpret_cast<CSEMIStdGUIApp*>(pThis);

>> // The following method creates the sink and
>> // advises my MTA COM server

>> pThisObject->GUIAdvise();
>> while(1)
>> {

>> Sleep(100);

>> }
>>      CoUninitialize();
>>      return 1;
>> }

>> Do you think is there any problem in making my MTA
thread
>> alive my putting a while loop. (Later i am planning to
>> modify the above while loop by using an Event object as
>> the loop exit condition, so that this MTA thread dies
when
>> my GUI main thread exits.)

>> For me the above the Advise method from the GUI MTA
thread
>> works, But i have noticed that there is a significant
>> delay in receiving the callbacks when i do the above
>> method of advising the server from the MTA thread when
>> compared to the advise i do from the STA(normal case).

>> Even if i create this MTA to advise the sink, do you
think
>> is there any real perfomance benefits for me when
compared
>> to the advise the COM server from the STA??, because in
>> both the cases we need to post the message to the main
>> thread when we receive the callbacks from the MTA COM
>> server.

>> Your advice is highly appreciated.
>> Thanks & Regards
>> Karinta.(BAG)

>> >-----Original Message-----


>> >> Hi all,

>> >> I have some doubts about the type of threading model
i
>> >> should choose for my client application which is
>> accessing
>> >> the MTA COM server.
>> >> I am using ATL 3.0 for the COM server development and
>> MFC
>> >> gui as the client.

>> >> My concerns are the following

>> >> 1) Can i create the MFC gui client main thread to
join
>> the STA.

>> >You pretty much have to. GUI is thread-affine, it does
>> not work well in MTA.

>> >> 2) Is there any problem in receving multiple
callbacks
>> >> fired from the MTA COM server in the MFC gui, if i
>> create
>> >> my GUI in STA?.

>> >No problem, except that callbacks will be serialized,
so
>> that if two server
>> >threads call a callback at the same time, they need to
>> wait until the client
>> >processes the first callback, then the second one.

>> >> 3)Is there any advantage if i create the gui client
sink
>> >> interface alone in MTA to receive the callbacks
keeping
>> >> the GUI main thread in STA.

>> >Some people do that in order not to slow down the
server.
>> You spin an MTA
>> >thread and advise your sinks from there. When the event
>> arrives, the sink
>> >needs to notify the main thread somehow (usually by
>> posting a message) and
>> >returns immediately.

>> >> 4)If i create gui main thread in STA, can i make
other
>> >> threads created in the gui to join MTA( just to save
>> time
>> >> in marshalling the interface pointers between
>> apartments)

>> >You can create MTA worker threads, but it is real pain
to
>> do any GUI in MTA.
>> >Non-GUI components can be created in MTA just fine.
>> >--
>> >With best wishes,
>> >    Igor Tandetnik

>> >"For every complex problem, there is a solution that is
>> simple, neat, and
>> >wrong." H.L. Mencken

>> >.

>.



Mon, 24 May 2004 09:54:00 GMT  
 Threading model for the client application

Quote:
> BTW: Do you think is there any problem if i use
> Sendmessage to send the message to my GUI thread from my
> callback sink method. Does this block any pending
> callbacks? (Here the question is with respect to the GUI
> thread running in STA and no MTA to recieve the callbacks).

If you use SendMessage, you can just as well sink directly in the STA
thread. SendMessage is synchronous - it freezes sending thread until
receiving thread processes the message. You lose all benefits of sinking in
MTA. Use PostMessage instead.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat, and
wrong." H.L. Mencken



Mon, 24 May 2004 22:21:51 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Threading model for the MFC Client Application

2. what threading model is default when no Threading model key

3. Apartment Model Threading and Client Behavior

4. Apartment Model Threading and Client Behavior

5. Help in creating a WSAEventSelect model winsock client application

6. Software Engineer III - MFC- Pre-IPO company, client/server, intranet, multi-threaded applications

7. COM Threading Model for ISAPI Worker Threads

8. Exe server threading model - events from worker thread question

9. Looking for sample sockets client/server chat model

10. Smart Client Deployable Model

11. Threading Models

12. Changin Threading model causing serious problems

 

 
Powered by phpBB® Forum Software