473,320 Members | 2,088 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Calling Thread.Join() before leaving

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!
Nov 16 '05 #1
10 1886
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 [C# MVP]
www.cshrp.net - "Elegant code by witty programmers"
"Fernando Rodríguez" <fe*******************@fernando-rodriguez.com> wrote in
message news:8d********************************@4ax.com...
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!

Nov 16 '05 #2

"Patrik Löwendahl [C# MVP]" <pa**************@csharpsweden.com> wrote in
message news:eW**************@tk2msftngp13.phx.gbl...
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.
Nov 16 '05 #3
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 [C# MVP]
www.cshrp.net - "Elegant code by witty programmers"

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

"Patrik Löwendahl [C# MVP]" <pa**************@csharpsweden.com> wrote in
message news:eW**************@tk2msftngp13.phx.gbl...
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.

Nov 16 '05 #4
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote:
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 - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #5
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"

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote:
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 - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #6
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote:
My bad, the abort isn't called in a managed sense. Sorry for that..


No problem - just glad I hadn't missed something :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #7

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote:
Theoreticly,

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

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

http://msdn.microsoft.com/library/de...roundTopic.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.
Nov 16 '05 #8
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 [C# MVP]
www.cshrp.net - "Elegant code by witty programmers"

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eg**************@TK2MSFTNGP09.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote:
Theoreticly,

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


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

http://msdn.microsoft.com/library/de...roundTopic.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.

Nov 16 '05 #9

"Patrik Löwendahl [C# MVP]" <pa**************@csharpsweden.com> wrote in
message news:uY***************@TK2MSFTNGP11.phx.gbl...
--
Patrik Löwendahl [C# MVP]
www.cshrp.net - "Elegant code by witty programmers"

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eg**************@TK2MSFTNGP09.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote:
Theoreticly,

The framwork calls Abort on all background threads when there's no more
foreground threads.
I was going by the online docs for Thread.IsBackground:

http://msdn.microsoft.com/library/de...roundTopic.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.

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.
Nov 16 '05 #10
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.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Patrik Löwendahl [C# MVP] <pa**************@csharpsweden.com> wrote:
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 - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

8
by: Matthew Bell | last post by:
Hi, I've got a question about whether there are any issues with directly calling attributes and/or methods of a threaded class instance. I wonder if someone could give me some advice on this. ...
13
by: Deepak Sarda | last post by:
Hello everyone. I have run into something which I believe is a bug or a shortcoming of the threading.Thread module. My program spawns 15 threads. For this I've creating a new class with...
8
by: Steven Bethard | last post by:
I'm playing around with some threading stuff right now, and I'm having a little trouble calling a function from one thread that affects another. Here's my setup: py> import os, threading, time...
4
by: Gilles Leblanc | last post by:
Hi I have started a small project with PyOpenGL. I am wondering what are the options for a GUI. So far I checked PyUI but it has some problems with 3d rendering outside the Windows platform. I...
0
by: Bryan | last post by:
I have a multi-threaded C# console application that uses WMI (System.Management namespace) to make RPC calls to several servers (600+ ) and returns ScheduledJobs. The section of my code that...
15
by: Bryan | last post by:
I have a multi-threaded C# console application that uses WMI (System.Management namespace) to make RPC calls to several servers (600+ ) and returns ScheduledJobs. The section of my code that...
4
by: fred | last post by:
I use a Synclock in a secondary thread and also stop the thread using the abort method. If the abort occurs while the thread is in the Synclock will the SyncLock always be released before the...
14
by: Joe | last post by:
Does anyone know the difference, in practical terms, between Thread.Sleep (10000) and Thread.CurrentThread.Join (10000)?? The MSDN says that with Join, standard COM and SendMessage pumping...
1
by: dshereck | last post by:
Hello, I implemented a simple c++ thread wrapper; it works in Linux, but fails in BSD. Here is the code. The idea is that an other class will inherit and implement the virtual methods Setup...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.