[omniORB] Single Threaded Policy: really same thread?

[Kevin Matassa]

Sorry, but I'm still left with the same question.  Based on my debugging it
looks like OmniORB doesn't reliably use the same thread calling into my
implementation object, even when I've set the SINGLE_THREAD policy on its
poa.  Can anyone confirm this?
 
The libraries that I must use within context of my implemention dictate that
the same thread is being used.  This is beyond my control.

Thanks again.
-Kevin

-----Original Message-----
From: Kevin Wooten [mailto:kwooten@itracs.com] 
Sent: December 16, 2002 7:55 PM
To: bjensen@fastmail.fm; Kevin Matassa
Cc: omniorb-list@omniorb-support.com
Subject: RE: [omniORB] Single Threaded Policy: really same thread?


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