Calling Thread.Join() before leaving

[Fernando Rodríguez]

Hi,

Assume I have Main function that looks like this:

static void Main(string[] args)
{

Action h1 = new Action(0);


Thread hilo1 = new Thread( new ThreadStart( h1.go ));
hilo1.Start();
}

What will happen if the thread I created hasn't finished when the main thread
exits Main()?

Is it advisable to call hilo1.Join() before exiting Main() ?

How's this thing handled usually? O

Thanks!

 

[Patrik Löwendahl [C# MVP]]

If the thread is a background thread, it will be terminated with the
application.

If it's not a background thread, the process will live until the thread
returns.

To indicate it as a background thread, set the property IsBackground to true
on the thread object.

 

[Mike Schilling]

If the thread is a background thread, it will be terminated with the
application.

If it's not a background thread, the process will live until the thread
returns.

To indicate it as a background thread, set the property IsBackground to
true on the thread object.

I was about to respond that IsBackground can only be set before the thread
is started, but you're absolutely right, it's a fully mutable property.
Which leads me to the following question: is the following program
guaranteed to terminate?

using System;
using System.Threading;

class Background {
public static void Main() {
Background b = new Background();
Thread t = new Thread(new ThreadStart(b.DoSleep));
t.Start();
}

public void DoSleep() {
Thread.Sleep(5000);
Thread.CurrentThread.IsBackground = true;
Thread.CurrentThread.IsBackground = false;
while (true) { }
}

}

It does terminate, for me, as a console program built with .NET 1.1, but I
don't see any guarantee in the documentation that, at the moment a thread is
set to background, the state of all threads will be checked, and termination
will occur if no foreground threads remain.

I admit that this is largely of academic interest, since I can't picture it
ever being necessary to depend upon this behavior rather than doing
something more straightforward.

 

[Patrik Löwendahl [C# MVP]]

Theoreticly,

The framwork calls Abort on all background threads when there's no more
foreground threads. So theoreticly it would always terminate since there's
no more foreground threads when you mark that one as a background thread.

 

[Jon Skeet [C# MVP]]

Theoreticly,

The framwork calls Abort on all background threads when there's no more
foreground threads.

Really? Is this documented somewhere? I thought the process just
terminated when there were no more foreground threads. That's quite
different from Abort being called, as Abort allows for some clean-up.

 

[Patrik Löwendahl [C# MVP]]

My bad, the abort isn't called in a managed sense. Sorry for that..

--
Patrik Löwendahl [C# MVP]
www.cshrp.net - "Elegant code by witty programmers"

Theoreticly,

The framwork calls Abort on all background threads when there's no more
foreground threads.

Really? Is this documented somewhere? I thought the process just
terminated when there were no more foreground threads. That's quite
different from Abort being called, as Abort allows for some clean-up.

 

[Jon Skeet [C# MVP]]

My bad, the abort isn't called in a managed sense. Sorry for that..

No problem - just glad I hadn't missed something

 

[Mike Schilling]

I was going by the online docs for Thread.IsBackground:

http://msdn.microsoft.com/library/d...stemThreadingThreadClassIsBackgroundTopic.asp

A thread is either a background thread
or a foreground thread. Background
threads are identical to foreground threads,
except that background threads do not prevent
a process from terminating. Once all foreground
threads belonging to a process have terminated,
the common language runtime ends the process
by invoking Abort on any background threads that
are still alive

Taken literally, it doesn't apply, since no threads were terminated.
Perhaps there's a more precise statement elsewhere.

Really? Is this documented somewhere? I thought the process just
terminated when there were no more foreground threads. That's quite
different from Abort being called, as Abort allows for some clean-up.

It does say that Abort is called; I haven't tried it.

 

[Patrik Löwendahl [C# MVP]]

It's not effectivly doing a managed abort on the thread since no ThreadAbort
(nor ThreadInterrupt) Exception is throwed so I would imgine that they're
talking in an unmanaged sense.

 

[Mike Schilling]

--
Patrik Löwendahl [C# MVP]
www.cshrp.net - "Elegant code by witty programmers"

I was going by the online docs for Thread.IsBackground:

http://msdn.microsoft.com/library/d...stemThreadingThreadClassIsBackgroundTopic.asp

A thread is either a background thread
or a foreground thread. Background
threads are identical to foreground threads,
except that background threads do not prevent
a process from terminating. Once all foreground
threads belonging to a process have terminated,
the common language runtime ends the process
by invoking Abort on any background threads that
are still alive

Taken literally, it doesn't apply, since no threads were terminated.
Perhaps there's a more precise statement elsewhere.


It does say that Abort is called; I haven't tried it.

It's not effectivly doing a managed abort on the thread since no
ThreadAbort (nor ThreadInterrupt) Exception is throwed so I would imgine
that they're talking in an unmanaged sense.

Iin "invoking Abort on any background threads" in the online docs, "Abort"
is a hyperlink to the Thread.Abort method. I don't see that behavior, but
it's certainly what the documentation says.

 

[David Levine]

Actually, it's fairly well documented that it does NOT call abort, or
perform any other cleanup, when the process is about to be terminated. A
simple console app can demonstrate that...start a background thread with a
finally block that prints something out to the console/trace/whatever, and
then exit the main thread...you should find that the finally block never
executes.

Theoreticly,

The framwork calls Abort on all background threads when there's no more
foreground threads.

Really? Is this documented somewhere? I thought the process just
terminated when there were no more foreground threads. That's quite
different from Abort being called, as Abort allows for some clean-up.