20

Using code like the code below, will the new thread created end on its own after the function returns?

new Thread(() =>
{
    function();
}).Start();

I'm pretty new to threading, so I wondered.

Lee Taylor
  • 7,761
  • 16
  • 33
  • 49
PhoenixLament
  • 741
  • 1
  • 11
  • 32
  • It is always a good idea to manage your threads; regardless of how you invoke them. Garbage Collection does a good job of managing out-of-scope objects, but that is no replacement for good coding practices. – Brian Mar 17 '13 at 15:32
  • 1
    It will end on its own, but you might want to make it a background thread so it ends if the application is closed instead of keeping it secretly alive. Depends on the situation, though. – Ry- Mar 17 '13 at 15:38
  • 1
    @Brian: What does that mean and what does garbage collection have to do with anything? – Ry- Mar 17 '13 at 15:39
  • @minitech Ultimately it's the GC which actually cleans up the threads. The runtime holds a reference to the thread until it's finished executing then removes the reference which allows the GC to do it's bit. I think Brian was just trying to point out that it's generally a better approach to use explicit object cleanup when possible. – James Mar 17 '13 at 15:44
  • 1
    Just out of curiosity... why not use `Task` instead of `Thread`? Are you limited to older .NET versions? – MBender Mar 17 '13 at 15:59
  • @Shaamaan i'm not aware of `Task`, and the difference in that and `Thread` – PhoenixLament Mar 17 '13 at 16:04
  • @Shaamaan nevermind, i think i understand now. Based off the info here: [link](http://stackoverflow.com/questions/4130194/what-is-the-difference-between-task-and-thread), and I need to have the function i call execute in parallel with the gui thread. – PhoenixLament Mar 17 '13 at 16:09
  • Exactly what `Tasks`s are good for. :) Indeed, you can still use `Thread`s, but `Task`s are designed to make, well, multitasking and asynchronous operations easier. In that regard, given what you want to do, a `Task` will definitely work. Not strictly better, but the code should be easier to write and maintain in the end. – MBender Mar 18 '13 at 08:46

3 Answers3

15

That's fine... if it's a concern that the Thread might not complete before your executable quits, you might want:

new Thread(() =>
    {
        function();
    }){IsBackground = true}.Start();

Background threads will not prevent your app from exiting.

spender
  • 117,338
  • 33
  • 229
  • 351
  • thanks spender, i think the only case where I would have a thread try and outlast the executable is if the executable unexpectedly crashes or some other freak event. – PhoenixLament Mar 17 '13 at 15:45
2

Yes, the thread will end after the function completes, but unless you have a parameter you need to use inside the function I wouldn't start it like that; I would just do:

new Thread(function).Start();
Ry-
  • 218,210
  • 55
  • 464
  • 476
Naate
  • 115
  • 10
  • In most cases you should not start new thread like this. Check what TPL is. – vittore Mar 17 '13 at 15:40
  • thanks, I do have some cases of the code I posted with parameters, so I presume my method for that is correct? – PhoenixLament Mar 17 '13 at 15:40
  • 1
    Yes. i use multithreading my applications all the time and usually i try to avoid having parameters to start with in new threads. starting threads is very simple and usually you would only need to "kill" them if they are looping where they wont end them selves. – Naate Mar 17 '13 at 15:46
  • I have placed timers to 'return' when 25-30 seconds have elapsed and the task is not completing as designed. – PhoenixLament Mar 17 '13 at 15:47
  • 1
    usually if the task isn't completed within an expected time in a thread it is usually because it's been caught in a loop. – Naate Mar 17 '13 at 15:48
  • i've placed timeout conditions for the loops as well – PhoenixLament Mar 17 '13 at 15:50
2

Although it's considered best practise to manage your threads, if you aren't interested in the result/state of that particular thread and don't need to deal with cancellation etc. then what your doing is fine.

It's worth considering whether or not you need a dedicated thread for what you're doing. If the code you are running is relatively small you might want to consider utilising the ThreadPool via the TPL or QueueUserWorkItem instead.

James
  • 80,725
  • 18
  • 167
  • 237