Possible huge clue into unmanged/managed problem

[_BNC]

Recently I had posted a query about intermittent problems with a
C++/Interop scheme (unmanaged C DLL wrapped in unmanaged C++,
wrapped in managed C++, all accessed by C#). The system works fine
when unstressed, but fails under stress.

Well...I just noticed short mention in Prosise's book, of all places,
re threading. He indicated that the behavior of unmanaged code within
managed threads is not predictable. I had thought that the organized
internal alloc/shutdown within the embedded unmanaged classes was
good enough to keep things in line. Maybe not.

Do I need to take all the unmanaged code out to an UNmanaged thread?
(Yechh!) Is this documented anywhere?

_B

[Alvin Bruney [MVP]]

I wouldn't think so. What is the context of Prosise' statement? I'm sure it
won't infringe copywrites if you post a replication/summation

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://tinyurl.com/27cok
----------------------------------------------------------
"_BNC" <_B**@noemail.o rg> wrote in message
news:in******** *************** *********@4ax.c om...

Recently I had posted a query about intermittent problems with a
C++/Interop scheme (unmanaged C DLL wrapped in unmanaged C++,
wrapped in managed C++, all accessed by C#). The system works fine
when unstressed, but fails under stress.

Well...I just noticed short mention in Prosise's book, of all places,
re threading. He indicated that the behavior of unmanaged code within
managed threads is not predictable. I had thought that the organized
internal alloc/shutdown within the embedded unmanaged classes was
good enough to keep things in line. Maybe not.

Do I need to take all the unmanaged code out to an UNmanaged thread?
(Yechh!) Is this documented anywhere?

_B

[_BNC]

On Mon, 31 Jan 2005 12:05:54 -0400, "Alvin Bruney [MVP]" <vapor at
steaming post office> wrote:

I wouldn't think so. What is the context of Prosise' statement? I'm sure it
won't infringe copywrites if you post a replication/summation

I doubt that Jeff would mind. p668, under 'terminating threads':

"Abort throws a ThreadAbortExce ption in the targeted thread, causing the
thread to edn. The thread might not end immediately; in fact, it's not
guaranteed to end at all. If the thread has called out to unmanaged code,
for example, and hasn't yet returned, it doesn't terminate until it begins
executing managed code again. ..."

I hadn't expected much on unmanaged code in Jeff's book, but I still
haven't got a solid grip on what is going on in mgd/unmgd, so in my spare
time I've been combing through all my books and references to unmanaged
code.

The scenario above could happen, I think, as the original code was
designed to loop til it got a result-- or until its thread was aborted.
It hadn't occurred to me that the *managed thread* can no longer control
some of the code inside the thread. The symptoms don't all match up,
but that's par for this program.

[Daniel Petersson, Cefalo]

I didn't read your old post about your problem but
I think a good design is to avoid methods like Thread.Abort
or / and TerminateThread since they always cause you
problem in the "long" run. I think a more controlled signal
is needed when you whish to shut down your thread.
You could use an w32 event object for this notification,
it is possible to access these from managed code as well

// daniel

"_BNC" wrote:

On Mon, 31 Jan 2005 12:05:54 -0400, "Alvin Bruney [MVP]" <vapor at
steaming post office> wrote:

I wouldn't think so. What is the context of Prosise' statement? I'm sure it
won't infringe copywrites if you post a replication/summation

I doubt that Jeff would mind. p668, under 'terminating threads':

"Abort throws a ThreadAbortExce ption in the targeted thread, causing the
thread to edn. The thread might not end immediately; in fact, it's not
guaranteed to end at all. If the thread has called out to unmanaged code,
for example, and hasn't yet returned, it doesn't terminate until it begins
executing managed code again. ..."

I hadn't expected much on unmanaged code in Jeff's book, but I still
haven't got a solid grip on what is going on in mgd/unmgd, so in my spare
time I've been combing through all my books and references to unmanaged
code.

The scenario above could happen, I think, as the original code was
designed to loop til it got a result-- or until its thread was aborted.
It hadn't occurred to me that the *managed thread* can no longer control
some of the code inside the thread. The symptoms don't all match up,
but that's par for this program.

[Alvin Bruney [MVP]]

I'm wondering out loud if the CLR team cannot provide a cleaner way to
terminate a thread that would be internally implemented?

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://tinyurl.com/27cok
----------------------------------------------------------
"Daniel Petersson, Cefalo" <da************ **@cefalo.se.do notspam> wrote in
message news:D0******** *************** ***********@mic rosoft.com...

I didn't read your old post about your problem but
I think a good design is to avoid methods like Thread.Abort
or / and TerminateThread since they always cause you
problem in the "long" run. I think a more controlled signal
is needed when you whish to shut down your thread.
You could use an w32 event object for this notification,
it is possible to access these from managed code as well

// daniel

"_BNC" wrote:

On Mon, 31 Jan 2005 12:05:54 -0400, "Alvin Bruney [MVP]" <vapor at
steaming post office> wrote:

>I wouldn't think so. What is the context of Prosise' statement? I'm sure
>it
>won't infringe copywrites if you post a replication/summation

I doubt that Jeff would mind. p668, under 'terminating threads':

"Abort throws a ThreadAbortExce ption in the targeted thread, causing the
thread to edn. The thread might not end immediately; in fact, it's not
guaranteed to end at all. If the thread has called out to unmanaged
code,
for example, and hasn't yet returned, it doesn't terminate until it
begins
executing managed code again. ..."

I hadn't expected much on unmanaged code in Jeff's book, but I still
haven't got a solid grip on what is going on in mgd/unmgd, so in my spare
time I've been combing through all my books and references to unmanaged
code.

The scenario above could happen, I think, as the original code was
designed to loop til it got a result-- or until its thread was aborted.
It hadn't occurred to me that the *managed thread* can no longer control
some of the code inside the thread. The symptoms don't all match up,
but that's par for this program.

[Willy Denoyette [MVP]]

The CLR depends on the OS service offered to terminate a (OS) thread, and
it's that service (TerminateThrea d) which is "dangerous by nature".

Willy.

"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:uE******** ******@TK2MSFTN GP15.phx.gbl...

I'm wondering out loud if the CLR team cannot provide a cleaner way to
terminate a thread that would be internally implemented?

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://tinyurl.com/27cok
----------------------------------------------------------
"Daniel Petersson, Cefalo" <da************ **@cefalo.se.do notspam> wrote in
message news:D0******** *************** ***********@mic rosoft.com...

I didn't read your old post about your problem but
I think a good design is to avoid methods like Thread.Abort
or / and TerminateThread since they always cause you
problem in the "long" run. I think a more controlled signal
is needed when you whish to shut down your thread.
You could use an w32 event object for this notification,
it is possible to access these from managed code as well

// daniel

"_BNC" wrote:

On Mon, 31 Jan 2005 12:05:54 -0400, "Alvin Bruney [MVP]" <vapor at
steaming post office> wrote:

>I wouldn't think so. What is the context of Prosise' statement? I'm
>sure it
>won't infringe copywrites if you post a replication/summation

I doubt that Jeff would mind. p668, under 'terminating threads':

"Abort throws a ThreadAbortExce ption in the targeted thread, causing the
thread to edn. The thread might not end immediately; in fact, it's not
guaranteed to end at all. If the thread has called out to unmanaged
code,
for example, and hasn't yet returned, it doesn't terminate until it
begins
executing managed code again. ..."

I hadn't expected much on unmanaged code in Jeff's book, but I still
haven't got a solid grip on what is going on in mgd/unmgd, so in my
spare
time I've been combing through all my books and references to unmanaged
code.

The scenario above could happen, I think, as the original code was
designed to loop til it got a result-- or until its thread was aborted.
It hadn't occurred to me that the *managed thread* can no longer
control
some of the code inside the thread. The symptoms don't all match up,
but that's par for this program.

[cody]

You simply have to call return from the thread method to terminate a thread
the clean way.

"Alvin Bruney [MVP]" <vapor at steaming post office> schrieb im Newsbeitrag
news:uE******** ******@TK2MSFTN GP15.phx.gbl...

I'm wondering out loud if the CLR team cannot provide a cleaner way to
terminate a thread that would be internally implemented?

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://tinyurl.com/27cok
----------------------------------------------------------
"Daniel Petersson, Cefalo" <da************ **@cefalo.se.do notspam> wrote in
message news:D0******** *************** ***********@mic rosoft.com...

I didn't read your old post about your problem but
I think a good design is to avoid methods like Thread.Abort
or / and TerminateThread since they always cause you
problem in the "long" run. I think a more controlled signal
is needed when you whish to shut down your thread.
You could use an w32 event object for this notification,
it is possible to access these from managed code as well

// daniel

"_BNC" wrote:

On Mon, 31 Jan 2005 12:05:54 -0400, "Alvin Bruney [MVP]" <vapor at
steaming post office> wrote:

>I wouldn't think so. What is the context of Prosise' statement? I'm sure >it
>won't infringe copywrites if you post a replication/summation

I doubt that Jeff would mind. p668, under 'terminating threads':

"Abort throws a ThreadAbortExce ption in the targeted thread, causing the thread to edn. The thread might not end immediately; in fact, it's not
guaranteed to end at all. If the thread has called out to unmanaged
code,
for example, and hasn't yet returned, it doesn't terminate until it
begins
executing managed code again. ..."

I hadn't expected much on unmanaged code in Jeff's book, but I still
haven't got a solid grip on what is going on in mgd/unmgd, so in my spare time I've been combing through all my books and references to unmanaged
code.

The scenario above could happen, I think, as the original code was
designed to loop til it got a result-- or until its thread was aborted.
It hadn't occurred to me that the *managed thread* can no longer control some of the code inside the thread. The symptoms don't all match up,
but that's par for this program.

[Willy Denoyette [MVP]]

"cody" <de********@gmx .de> wrote in message
news:u0******** ******@TK2MSFTN GP10.phx.gbl...

You simply have to call return from the thread method to terminate a
thread
the clean way.

And what if the thread is blocked or is in an infinite loop?
There is nothing wrong with Thread.Abort as long as you call it
synchronously. When called asynchronously you have to terminate the process
when done or unload the application domain if not running in the primary
domain.

Willy.

[cody]

What do you mean with "terminate the process"? Why should I have to
terminate the whole application if I only want to terminate one thread? And
if a terminate the last thread in an application shouldn't the process be
terminated automatically by the system?

"Willy Denoyette [MVP]" <wi************ *@pandora.be> schrieb im Newsbeitrag
news:OO******** ******@tk2msftn gp13.phx.gbl...

"cody" <de********@gmx .de> wrote in message
news:u0******** ******@TK2MSFTN GP10.phx.gbl...

You simply have to call return from the thread method to terminate a
thread
the clean way.

And what if the thread is blocked or is in an infinite loop?
There is nothing wrong with Thread.Abort as long as you call it
synchronously. When called asynchronously you have to terminate the
process when done or unload the application domain if not running in the
primary domain.

Willy.

[Willy Denoyette [MVP]]

If you happen to abort a thread asynchronously, that means an exception can
bet thrown at any moment during program execution, you possibly have
corrupted the application state.
Consider following thread procedure

void SomeProc()
{
lock(myLock)
{
}
}
, when the exception is thrown during the execution of the finalize clause
(compiler generated from lock()), chances are that the lock is not released.
If it happens that you are executing unmanaged code during Abort, chances
are that locks held by your unmanaged code will not being released, buffers
not freed, semaphores not cleared etc.
If it happens during managed execution of global state initialization
(static's), you'll end with incorrectly initialized global state.

So, I think it's clear there is no other option then to exit the process or
throw away the application domain.

Not sure what you mean with:
terminate the last thread in an application shouldn't the process be

terminated automatically by the system?
calling Thread.Abort on your current thread, is a synchronous Abort
(synchronous exception), and yes if it happens on the last managed thread in
the application, the CLR will shutdown the process.

Willy.


"cody" <de********@gmx .de> wrote in message
news:%2******** *********@TK2MS FTNGP10.phx.gbl ... What do you mean with "terminate the process"? Why should I have to
terminate the whole application if I only want to terminate one thread?
And if a terminate the last thread in an application shouldn't the process
be terminated automatically by the system?

"Willy Denoyette [MVP]" <wi************ *@pandora.be> schrieb im
Newsbeitrag news:OO******** ******@tk2msftn gp13.phx.gbl...

"cody" <de********@gmx .de> wrote in message
news:u0******** ******@TK2MSFTN GP10.phx.gbl...

You simply have to call return from the thread method to terminate a
thread
the clean way.

And what if the thread is blocked or is in an infinite loop?
There is nothing wrong with Thread.Abort as long as you call it
synchronously. When called asynchronously you have to terminate the
process when done or unload the application domain if not running in the
primary domain.

Willy.