0

I have just started researching threads for use in a program I have created. I have a few questions that I think I know the answer to, but could use some clarification on.

Once a thread is created, is it always alive/live/there (unsure of proper description) until aborted?

When a thread is aborted/stopped, it will only abort by throwing an error?

If the above (aborting throws an error) is true, how do I incorporate this into an existing try/catch without the existing catch commands being run every time the thread is ended?

As I said, I am just beginning to learn about threads, so excuse me if the question is a bit too "Noob". I am finding a lot of information, but the more information I get, the more questions I have.

Thank you

DDuffy
  • 413
  • 1
  • 4
  • 21

2 Answers2

2

Once a thread is created, is it always alive/live/there (unsure of proper description) until aborted?

NO, it will be live until the execution of the method block is not completed. It's no more live once the execution completes.

If it's a non threadpool thread then it's over and become non-usable but if it's threadpool thread then it goes and sits back in pool. So that, it can be assigned a new request whenever comes in.

When a thread is aborted/stopped, it will only abort by throwing an error?

Yes it will throw a ThreadAbortException but why will you abort though?

If you mean to cancel it then try using BackGroundWorker or System.Threading.Tasks.Task instead. See Task Cancellation

Rahul
  • 76,197
  • 13
  • 71
  • 125
  • So once my thread has reached the end, it is disposed of? Pretty sure I'm not using a threadpool, as this is the first time i have heard of it. (great, another thing for me to research.) – DDuffy Jul 20 '16 at 11:48
  • @DDuffy, Yes it will. It no more exists and neither `Tread` class provides you a `Dispose()` method. – Rahul Jul 20 '16 at 11:52
  • @DDuffy of you're learning about threading and your tutorial hasn't mentioned thread pools yet get a new tutorial, you're not going to learn the important things from the one you're using right now. – Voo Jul 20 '16 at 12:00
1

To clarify ...

Any thread probably should "run until it stops itself." That is to say, until it terminates normally. If you wish for it to stop sooner, I suggest that you should in some suitable way signal it to "stop what it is doing and exit as soon as possible."

(It is also useful to think of a thread or process as a worker which might complete many units of work during its lifetime. Setting-up and tearing-down such a thing is expensive compared to letting it live a long and productive life ...)

It's never a good idea to point a gun at the head of a process or thread and just pull the trigger, because you have no way of knowing what it might have been "in the middle of doing" when the fatal bullet arrived. Anything might happen, and you'll never be able to reproduce it.

Yes, an "un-caught exception" will cause a thread or process to die ... and, especially in the case of a thread (which shares memory and everything-else with its companions), this could be a bellwether of more serious application bugs, which you won't be able to easily detect. Therefore, I advise that you should always use an error-catch mechanism in the outermost handler of any thread or process. Allow the thread to catch and (try to) report the error before: "it terminates itself as graciously as possible."

Mike Robinson
  • 8,490
  • 5
  • 28
  • 41