Calling Thread.Join() before leaving

  • Thread starter Thread starter Fernando Rodríguez
  • Start date Start date
F

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!
 
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.
 
Patrik Löwendahl said:
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.
Click to expand...

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.
 
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.
 
Patrik Löwendahl said:
Theoreticly,

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

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.
 
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"

Patrik Löwendahl said:
Theoreticly,

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

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.
 

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.
Click to expand...

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.
 
Patrik Löwendahl said:
--
Patrik Löwendahl [C# MVP]
www.cshrp.net - "Elegant code by witty programmers"

Mike Schilling said:
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.
Click to expand...
Click to expand...
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.
Click to expand...

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.
 
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.

Patrik Löwendahl said:
Theoreticly,

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

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.
 
Back
Top