[omniORB] Single Threaded Policy: really same thread?

[Kevin Wooten]

This is a bit off topic but very related and eating away at me...

I am very familiar with COM threading; this scheme of using the same
exact thread is exactly what COM does for all single threaded
components. Basically whatever thread creates a COM component assigns it
an apartment, which is basically a thread group. For single threaded
apartments this group is limited to one thread, for the multiple thread
apartment it can be as many as you like. All access to components must
be from threads within its thread group. This means that all requests to
components in a single threaded apartment are transferred to that
specific thread! Even worse, all access FROM single threaded components
TO also incur a thread transfer. Sounds to me it is exactly what Kevin
is expecting, but VERY time consuming, in all cases.

Now on to my question...

I was recently comparing CORBA to COM/DCOM when the question arose as to
why this model was chosen for COM. It seems to me that this is very time
consuming. I know special situations occur where global data is accessed
and some method is needed to ensure that two or more "single threaded"
components being run on different threads don't access global data at
the same time, and this may be through an API in which case you cannot
yourself protect the global data, (precisely why omniORB provides the
"main thread model"). Can anyone tell me why this method was chosen for
ALL components in COM?? MS's own documentation talks about access to
global data (basically the example I gave), but this can be solved by a
simple mutex! I have looked everywhere for this answer and cannot find
it. I cannot even find any more examples that warrant this method.
Anybody with some info on this or examples of why this is needed please
let me know.

As I said, it was a bit off topic, but I have been pondering this for a
while now and couldn't help but ask.

Cheers,
(a different)Kevin

-----Original Message-----
From: bjorn rohde jensen [mailto:bjensen@fastmail.fm] 
Sent: Monday, December 16, 2002 3:42 PM
To: Kevin Matassa
Cc: 'omniorb-list@omniorb-support.com'
Subject: Re: [omniORB] Single Threaded Policy: really same thread?

Hi Kevin,

  Why would that matter? I think, such a constraint
would only restrict the ORB implementation. I believe,
one of the basic design choices in omniORB was to try to
avoid the cost of thread context switches by letting
each invocation on an object be handled by the same
thread from arrival of the request to delivery of
the reply.

Yours sincerely,

Bjorn

_______________________________________________
omniORB-list mailing list
omniORB-list@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list