[omniORB] RE: omniORB-list digest, Vol 1 #245 - 9 msgs

[Kevin Wooten]

> -----Original Message-----
> From: JHJE (Jan Holst Jensen) [mailto:jhje@novonordisk.com]
> Sent: Tuesday, December 17, 2002 1:55 AM
> To: 'omniorb-list@omniorb-support.com'
> Subject: [omniORB] RE: omniORB-list digest, Vol 1 #245 - 9 msgs
> 
> > Subject: RE: [omniORB] Single Threaded Policy: really same thread?
> > Date: Mon, 16 Dec 2002 17:55:26 -0700
> > From: "Kevin Wooten" <kwooten@itracs.com>
> ...
> > 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
> 
> Yes, and that would exactly be one reason for wanting to use the same
> thread
> for all requests. If you make use of a COM server to complete the
request
> (as I do in some of my CORBA servers - effectively wrapping a COM API)
it
> would be very convenient if the ORB could guarantee that the thread
that
> instantiated the COM object would also be the one doing operations on
it.
> Otherwise, in order for the request not to fail, you would have to
make
> sure
> that each thread has called CoInitialize before invoking any methods
on
> the
> COM server. No big deal, but still some bookkeeping to do.
> 
> > 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
> 
> Well, the apartment model is used for all components in COM, but not
all
> apartments involve forcing a thread switch. If your COM server lives
in a
> "free-threaded" apartment, any thread is free to call it's methods
> directly.

This is a common belief that free-threaded components allow any thread
to issue requests directly on free-threaded objects, but is one you
should recheck! Requests from single threaded apartments to
free-threaded components ARE transferred to the multi-threaded
apartment. This is required to preserver apartment contexts. Look into
the reason for the threading style "both", which allows single threaded
apartments to create components as single threaded and multi threaded
apartments to create them multi threaded, but it does not stop the
thread switches. 

There is a new threading model for win2k and xp that is called
"neutral", that is supposed to cut out "SOME" of the thread switches,
but there is no real documentation on it (that I can find).
 
> It is then the responsibility of the COM server to protect it's
internal
> state or global data from concurrent access. So, if you are in control
of
> the COM server code, you can simple make sure it is thread-safe and
> configure it to run in an apartment with multiple threads. Actually, I
> think
> you can hack the registry to make any COM server run in a
"free-threaded"
> apartment, but if your server is not thread-safe be prepared for
> trouble...
> 
> Many third-party COM servers I've encountered like to run in a
> single-threaded apartment. When you don't have to think about thread-
> safety,
> it simply makes it easier to program the COM server. You'd rather have

IMHO, people who "don't have to think about thread safety" should not
really be using multiple threads. It is to dangerous and confusing of a
topic that most experienced programmers don't fully understand, and
trying to make it "easy" for them is somewhat crazy.

> something that is a bit slower and works than something fast that
crashes
> once in a while. So, I think the rationale has been to shield
entry-level
> programmers from threading issues (actually a wise decision IMHO),
with
> the
> downside of introducing the confusing concept of "apartments". Now, if
> they

Not only is the concept confusing, it is slowing everything down! To me
this is ludicrous!

> had only been named in a more logical way :-)...
> 
> Cheers
> 
> -- Jan Holst Jensen, Novo Nordisk A/S, Denmark
> _______________________________________________
> omniORB-list mailing list
> omniORB-list@omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list