Threading

  • Thread starter Thread starter Mark
  • Start date Start date
M

Mark

Hi,
Normally in what kind of situation system will abort a thread created
manually ? And how do I know the thread is aborted by system after I start
it?

Thanks!
Mark
 
Not sure what you mean with "system will abort thread", but in general such
threads are (should) never aborted, threads exists for the duration of your
thread procedure. If you need to know when a thread procedure has ended, you
have to call Thread.Join()
Willy.
 
The system will inject a ThreadAbortException into all threads that
originated in an appdomain that is being unloaded. This is the only time
AFAIK when the system will do that.
 
Are you sure about that?

All tests I've ever done never indicates a ThreadAbortException is
injected when the application domain is unloading. Isn't CLR just
killing them?
 
Patrik Löwendahl said:
Are you sure about that?

All tests I've ever done never indicates a ThreadAbortException is
injected when the application domain is unloading. Isn't CLR just
killing them?
Click to expand...

According to the docs for AppDomain.Unload:

<quote>
The threads in domain are terminated using the Abort method, which
throws the thread an instance of ThreadAbortException. Although the
thread should terminate promptly, it can continue executing for an
unpredictable amount of time in its finally clause.
</quote>

Here's a complete pair of programs to demonstrate it:

Test.cs - compile to test.exe
using System;

class Test
{
static void Main()
{
AppDomain dom = AppDomain.CreateDomain ("Foo");

dom.ExecuteAssembly ("test2.exe");

// By the time this returns, the other thread will be running

AppDomain.Unload(dom);
}
}

Test2.cs - compile to test2.exe
using System;
using System.Threading;

class Test2
{
static void Main()
{
new Thread (new ThreadStart(ThreadJob)).Start();
Thread.Sleep(100);
}

static void ThreadJob()
{
Console.WriteLine ("Executing in other app domain thread");
try
{
Thread.Sleep(2000);
}
catch (Exception e)
{
Console.WriteLine ("Got exception "+e);
}
}
}

Results:
Executing in other app domain thread
Got exception System.Threading.ThreadAbortException: Thread was being
aborted.
at System.Threading.Thread.Sleep(Int32 millisecondsTimeout)
at Test2.ThreadJob()
 
Thanks for the clarification.

A thought though.

What if the tread is in unmanaged space? The CLR will still need to wait
for it to come back to managed space?
 
Hmm, now I see why I was sceptic about the thread abort exception. Just
tried a similar scenario in the default domain. For that scenario, no
threadabort exception is caught by the try catch.

Could one assume then that an appdomain isn't unloaded in the same
manner as doing it manually and the process just dies taking it's
(bakground)threads with it?

test:

static void ThreadProc()
{
try
{
while(true)
{
Thread.Sleep(500);
Console.WriteLine("Tick...");
}

}
catch ( ThreadAbortException teax )
{
StreamWriter sw = new StreamWriter("C:\\temp\\meppo.txt");

sw.WriteLine(teax.ToString());

Thread.Sleep(10000);

Console.WriteLine ( "Thread aborted " );
Console.ReadLine();
}
catch ( Exception e )
{
Console.WriteLine ( "Exception {0}", e.Message);
}

}

static void Main(string[] args)
{
Thread t = new Thread( new ThreadStart ( ThreadProc ) );
t.IsBackground = true;
t.Start();

Thread.Sleep ( 2000 );
}
 
"Patrik Löwendahl [C# MVP]" said:
Hmm, now I see why I was sceptic about the thread abort exception. Just
tried a similar scenario in the default domain. For that scenario, no
threadabort exception is caught by the try catch.

Could one assume then that an appdomain isn't unloaded in the same manner
as doing it manually and the process just dies taking it's
(bakground)threads with it?
Click to expand...

The default application domain is never unloaded, it is thrown away when the
process terminates as a result of an orderly/unorderly shutdown.

Willy.
 
Patrik Löwendahl said:
Are you sure about that?

All tests I've ever done never indicates a ThreadAbortException is
injected when the application domain is unloading. Isn't CLR just
killing them?
Click to expand...

According to the docs for AppDomain.Unload:

<quote>
The threads in domain are terminated using the Abort method, which
throws the thread an instance of ThreadAbortException. Although the
thread should terminate promptly, it can continue executing for an
unpredictable amount of time in its finally clause.
</quote>

This is not exactly true, I guess it was done like this in an early beta of
the CLR, but now the CLR will inject a ThreadAbortExceptions into the
threads that must be unwound. This is more scalable than calling Abort, but
the effect is the same.

Willy.
 
Thanks a lot.
If I start 500 threads from a win app inside manually, how does system
handle it? Does system queue them up and run them once the system resource
(thread, memory etc.) available? All 500 threads would be guarantied to be
executed?

Thanks again,
Mark

Willy Denoyette said:
"Patrik Löwendahl [C# MVP]" said:
Hmm, now I see why I was sceptic about the thread abort exception. Just
tried a similar scenario in the default domain. For that scenario, no
threadabort exception is caught by the try catch.

Could one assume then that an appdomain isn't unloaded in the same manner
as doing it manually and the process just dies taking it's
(bakground)threads with it?
Click to expand...

The default application domain is never unloaded, it is thrown away when the
process terminates as a result of an orderly/unorderly shutdown.

Willy.
Click to expand...
 
Yes, all 500 threads would be started. The system does not queue them
up, the app will attempt to start all the 500 threads and execute each
according to the time-slicing factor.

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
Willy Denoyette said:
"Patrik Löwendahl [C# MVP]" said:
Hmm, now I see why I was sceptic about the thread abort exception. Just
tried a similar scenario in the default domain. For that scenario, no
threadabort exception is caught by the try catch.

Could one assume then that an appdomain isn't unloaded in the same manner
as doing it manually and the process just dies taking it's
(bakground)threads with it?
Click to expand...

The default application domain is never unloaded, it is thrown away when
the process terminates as a result of an orderly/unorderly shutdown.

Willy.
Click to expand...
That's basically it, but (as usual) it's a bit more complex then that...it
follows the procedure outlined by Chris Brumme in these blogs:

http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx
http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx

Finalizers are still run. Aborts are injected into threads in appdomains
other then the default. It's the difference between unloading an appdomain
and shutting down the application.
 
That's basically it, but (as usual) it's a bit more complex then that...it
follows the procedure outlined by Chris Brumme in these blogs:

http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx
http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx

Finalizers are still run. Aborts are injected into threads in appdomains
other then the default. It's the difference between unloading an appdomain
and shutting down the application.
Click to expand...

Davig,
True, but I didn't want to enter into these (implementation) details as
they may change from one version of the runtime to another.
My point was that Abort() wasn't used at all, "ThreadAbortExceptions" are
injected into the selected threads when unloading a (non default) domain.
When there's no other domain than the default domain, the CLR just starts
the process shutdown procedure perfectly outlined by Chris, there are no
thread aborts injected and no domain unloaded (the CLR doesn't even care
about it), but you should not take this as gospel as it as some details have
changed considerably in v2.

Willy.
 
True, but I didn't want to enter into these (implementation) details as
they may change from one version of the runtime to another.
My point was that Abort() wasn't used at all, "ThreadAbortExceptions" are
injected into the selected threads when unloading a (non default) domain.
When there's no other domain than the default domain, the CLR just starts
the process shutdown procedure perfectly outlined by Chris, there are no
thread aborts injected and no domain unloaded (the CLR doesn't even care
about it), but you should not take this as gospel as it as some details
have changed considerably in v2.
Click to expand...
I've played with Whidbey a little but currently I am still developing on
v1.1. I know there's lots of new goodies coming down that should improve
things quite a bit. Thanks for the heads up.
 
Back
Top