• 0

[C#] - Block Thread or Stop Thread & Respawn Later


Question

Hi. In my other recent post - [C#] - lock(...) and new Thread - I show how I am letting a client start/pause/resume a class that is doing work using threads it spawns off.

I have seen other alternatives to my method which use the ManualResetEvent to block the thread rather than to actually stop it (save work state) and then start up a new thread when the client calls Resume().

I just wanted to know if anyone knows the various advantages between the two alternatives. It seems to me that using ManualResetEvent is wasteful as it just leaves a Thread sleeping/blocked rather than actually releasing the thread as my current method does. On the other hand, the ManualResetEvent looks easier to implement and also seems like a more standard approach (though I've done no research into the matter).

Thanks for your advice.

Link to comment
Share on other sites

3 answers to this question

Recommended Posts

  • 0

I suppose it depends what you are doing with the Threads.

Say you are downloading files from the web, it would be better to kill the thread and close any file streams and then create a new thread when you wish to resume the download, to stop lots of resources being open and what not.

I can't actually think why you would want to pause a thread and keep all the current resources from that thread open, unless its a VERY CPU intensive task, then pausing the thread to allow other programs to work may be a good solution, for tasks such as video encoding.

Link to comment
Share on other sites

  • 0

Thanks again MiG. That makes sense.

I was also wondering if there are any best practices or official guidelines to my question. Let's say that both methods use the same amount of resources/time/space...if you had to pick one based on maintainability and convention, which method - if either - is better?

Link to comment
Share on other sites

  • 0
Thanks again MiG. That makes sense.

I was also wondering if there are any best practices or official guidelines to my question. Let's say that both methods use the same amount of resources/time/space...if you had to pick one based on maintainability and convention, which method - if either - is better?

I think from a coding standards point of view, killing the thread is a better option to follow, because if you just stop the thread code from running, the loop is still being executed and the resources are being used, maybe not a lot, but this is bad coding practice imo.

I don't think the number of valid uses for pausing a thread without freeing its resources constitute enough to support it. Many Data classes can be serialized, so for a lot of the time if you are pausing something there is a substantial gap in between pausing the action and resuming, meaning that killing the thead, and saving its current state is probably almost always the best option to choose.

Video encoding tasks could probably still follow this approach, as in its barebones it will require a file stream, and a loop writing to that stream. Killing the stream and loop means that the action is paused, with the action to resume. I would always recommend killing the thread.

On maintainability, both methods are probably the same, as they both work in a specific way so if that concept is grasped then i doubt one would be harder to maintain than the other from a code point of view. Convetion wise, Killing the thread is the best option IMO.

I can't offer any links to official guidlines on this topic, but i'm pretty sure a google search or a post over at the MSDN forums may help you more :)

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.