NEOHAPSIS - Peace of Mind Through Integrity and Insight

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com

Neohapsis > Archives > MS DCOM Discussion> 2001-q2

From: Bardia Ghahremani (bghKABELFOON.NL)
Date: Wed Jun 27 2001 - 16:11:01 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Yong

What I conclude by what Mark is suggesting is that true concurrency is the
same piece of code accessed by multiple threads (something that can truly be
appreciated at a multi-processor machine). In the case of the STA it is a
single thread running in the apartment. So what happens is that when an STA
object makes an out of apartment call it hands over control to com services
which on its turn keeps the message loop alive (through the STA thread).
Normally reentrancy would mean the A calls B, B calls A. But I think because
of performance reasons the com services would allow other threads to send
messages to the loop too. The thing is that all the code (even the message
loop) is running on the same thread making standard concurrency techniques
(synchronization objects) useless.

Bardia

-----Original Message-----
From: Distributed COM-Based Code [mailto:DCOMDISCUSS.MICROSOFT.COM]On
Behalf Of Yong Xu
Sent: woensdag 27 juni 2001 19:46
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: Single threaded DCOM server acting Multi-Threaded while
waiti ng for callbacks to complete!

Mark,

This is not only re-entry issue, but also concurrent one. I just wrote a
test util to prove it because it shook my fundamental understanding of STA.
In the test, a client enters an STA and calls an STA component S1; the
method of S1 increase an internal count, create an MTA component M1 and call
a method of M1 then return. The method of M1 does nothing but wait for 2
seconds. Just before the client makes its call, it spins off a second STA
thread which gets the very same S1 and makes the same call. The 2 threads
coordinate in such a way that while S1 waits M1's call return, it serves
another incoming call. The result? Immediately after the first thread makes
the call, it reads the internal count of S1 back. The count increased twice.
The S1 served the two threads concurrently. I use GIT to pass the interface
of S1.

So components in STA do have concurrency issue.

Yong
MCSD

-----Original Message-----
From: Mark Billingham [mailto:markbillinghamBLUEYONDER.CO.UK]
Sent: Tuesday, June 26, 2001 6:09 PM
Subject: Re: Single threaded DCOM server acting Multi-Threaded while
waiting for callbacks to complete!

I would disagree, an STA does provide a form of synchronization (compared
with the truly asynchronous behaviour of the MTA), it just does not provide
serialization.
An STA allows re-entrancy by the same thread, but this only occurs at
defined points (i.e. when an outgoing call is in progress).

It is easy to confuse re-entrancy with concurrency, these are very different
things. Only when you have true asynchronous, concurrent behavior (i.e.
multiple threads) should you need to use any synchronization mechanisms.

An STA provides just as much syncronization as the windows message loop it
is based on, windows message loop have always allowed re-entrancy (window A
calls SendMessage to window B, and window B calls SendMessage back to window
A). No one I know has ever needed to use a mutex, semaphore, or critical
section in a windows procedure, and you don't need them in an STA either.

-----Original Message-----
From: Distributed COM-Based Code [mailto:DCOMDISCUSS.MICROSOFT.COM]On
Behalf Of Ole J Mengshoel
Sent: 27 June 2001 00:13
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: Single threaded DCOM server acting Multi-Threaded while waiting
for callbacks to complete!

Steve,

Thanks for the clear statement of the fact that STA does not
provide any synchronization. This has not been clearly
explained by many authors - after reading them one is left
with the impression that synchronization is not needed when
using STA. And this is WRONG!

That said, it appears that the issues of synchronization
is less pressing in STA than in MTA, since the former binds
components to one thread only.
However, the defensive programmer will have to assume that
synchronization issues will arise, both in STA and MTA.

Ole J.

Steve Swartz <steveswMICROSOFT.COM>DISCUSS.MICROSOFT.COM> on 06/26/2001
03:31:59 PM

Please respond to Distributed COM-Based Code <DCOMDISCUSS.MICROSOFT.COM>

Sent by: Distributed COM-Based Code <DCOMDISCUSS.MICROSOFT.COM>

To: DCOMDISCUSS.MICROSOFT.COM
cc:
Subject: Re: Single threaded DCOM server acting Multi-Threaded while
waiting for callbacks to complete!

Yes, if Object B is in the STA, then while the call
in (2) is active the call (3) can begin. This is not
a change from COM to COM+, the STA has always worked
that way. It is a mistake to assume that the STA gives
you "synchronization". All it does is bind components
to a thread.

As you say, if you install a VB component into a COM+
application, you get true synchronization.

-----Original Message-----
From: Tahsin Alam [mailto:tahsinalamYAHOO.COM]
Sent: Tuesday, June 26, 2001 1:05 PM
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: Single threaded DCOM server acting Multi-Threaded while
waiting for callbacks to complete!

To clarify Steve's comment:
(1) Client_A calls Object_B
(2) Object_B calls Object_C
(3) Client_D calls Object_B

Steve - are you saying that call #3 will start
executing inside of Object_B while Object_B is still
waiting for the return from Object_C? Also, has this
behavior changed from COM to COM+? This seems a pretty
big change!

Thanks for your comments, Steve, I am learning a lot.

----------------------------------------------------------------
Users Guide http://msdn.microsoft.com/workshop/essentials/mail.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]