[omniORB] Single Threaded Policy: really same thread?

[Kevin Wooten]

Kevin,
	SINGLE_THREAD only guarantees that a single thread can access
the object (basically it protects it with a mutex). If you are using
omniORB version 4 then use the MAIN_THREAD model. This will guarantee
that all access is done through the main thread. Coincidentally, this
also requires you to call orb::run or orb::perform_work from the main
thread.

-----Original Message-----
From: Kevin Matassa [mailto:kevin.matassa@adobe.com] 
Sent: Tuesday, December 17, 2002 7:38 AM
To: 'omniorb-list@omniorb-support.com'
Subject: RE: [omniORB] Single Threaded Policy: really same thread?

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
_______________________________________________
omniORB-list mailing list
omniORB-list@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list