By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,264 Members | 1,725 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,264 IT Pros & Developers. It's quick & easy.

Thread.Suspend()

P: n/a
Hi,

I'm using a second thread within my program to do some long
calculations, without locking up the UI:

worker = new Thread(new ThreadStart(myClass.Run));
worker.Start();

I want to be able to pause the calculating, so I'm using

worker.Suspend()
and
worker.Resume()

I'm not using any shared variables or such like resources which need to
be protected/mutex but the compiler is telling me that these two
commands are obsolete/depreciated, yet they both still function.

Is there a newer (better) way I should be doing this, or am I OK to be
using these?

Thanks

Andrew
Feb 19 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
On Sun, 19 Feb 2006 15:08:57 GMT, Andrew Bullock
<an*********************@ANDntlworldTHIS.com> wrote:
Is there a newer (better) way I should be doing this, or am I OK to be
using these?


You shouldn't use them because they're dangerous, though I don't
recall the details at the moment. There's no newer alternative way
either, you just have to use manual synchronization -- check for some
semaphore on the worker thread and go to sleep if it's set.
--
http://www.kynosarges.de
Feb 19 '06 #2

P: n/a
Hi Andrew,
using suspend on a thread is generally considered a bad idea because if
you stop a thread in mid execution you can run into deadlock and race
conditions. What if a thread is suspended inside a critical region, nothing
else will be able to access that region etc. A better way to handle thread
syncronization is through WaitHandles. They act like barriers to thread
execution, threads cannot pass through the WaitHandle until another thread
open the handle allowing the thread to pass through. There are two basic
flavours, AutoResetEvent which will close the handle (go from Signalled to
Unsignalled) once a single thread passes through, and the ManualResetEvent
which once set will allow multiple threads to pass until it is manually reset.

Here is an example where a worker thread is allowed to do some processing
but then must wait for the main Thread to signal to it that it can complete
the final part of its processing:

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;

namespace ConsoleApplication18
{
class Program
{
static void Main(string[] args)
{
AutoResetEvent waitHandle = new AutoResetEvent(false);

//start other thread
Worker worker = new Worker();
worker.DoSomeWork(waitHandle);

//let main UI thread so some processing
Console.WriteLine("Main thread working");
Thread.Sleep(5000);

Console.WriteLine("Main thread finished work, let other thread
continue");
waitHandle.Set();

Console.ReadLine();
}
}

class Worker
{
private WaitHandle waitHandle;

public void DoSomeWork(WaitHandle waitHandle)
{
this.waitHandle = waitHandle;

Thread t = new Thread(new ThreadStart(ProcessValues));
t.Start();
}

private void ProcessValues()
{
//Can run this anytime
for (int i = 0; i < 5; i++)
{
Console.WriteLine("processing:" + i);
}

//make sure I am allowed to keep going
this.waitHandle.WaitOne();

//Can only run this once main thread is happy
for (int i = 0; i < 5; i++)
{
Console.WriteLine("last processing:" + i);
}
}
}
}
using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;

namespace ConsoleApplication18
{
class Program
{
static void Main(string[] args)
{
AutoResetEvent waitHandle = new AutoResetEvent(false);

//start other thread
Worker worker = new Worker();
worker.DoSomeWork(waitHandle);

//let main UI thread so some processing
Console.WriteLine("Main thread working");
Thread.Sleep(5000);

Console.WriteLine("Main thread finished work, let other thread
continue");
waitHandle.Set();

Console.ReadLine();
}
}

class Worker
{
private WaitHandle waitHandle;

public void DoSomeWork(WaitHandle waitHandle)
{
this.waitHandle = waitHandle;

Thread t = new Thread(new ThreadStart(ProcessValues));
t.Start();
}

private void ProcessValues()
{
//Can run this anytime
for (int i = 0; i < 5; i++)
{
Console.WriteLine("processing:" + i);
}

//make sure I am allowed to keep going
this.waitHandle.WaitOne();

//Can only run this once main thread is happy
for (int i = 0; i < 5; i++)
{
Console.WriteLine("last processing:" + i);
}
}
}
}

Hope that helps
Mark Dawson

--
http://www.markdawson.org
"Andrew Bullock" wrote:
Hi,

I'm using a second thread within my program to do some long
calculations, without locking up the UI:

worker = new Thread(new ThreadStart(myClass.Run));
worker.Start();

I want to be able to pause the calculating, so I'm using

worker.Suspend()
and
worker.Resume()

I'm not using any shared variables or such like resources which need to
be protected/mutex but the compiler is telling me that these two
commands are obsolete/depreciated, yet they both still function.

Is there a newer (better) way I should be doing this, or am I OK to be
using these?

Thanks

Andrew

Feb 19 '06 #3

P: n/a
Its always a good idea to try to know why you are not suppose to do
something, rather than just accepting a blanket statement, otherwise how do
you know when not to do it. Not looking into these things will lead to
comments like "Throwing Exceptions are expensive, don't ever throw them" or
"Never concatenate strings, always use a string builder" :-)

Mark.
--
http://www.markdawson.org
"Christoph Nahr" wrote:
On Sun, 19 Feb 2006 15:08:57 GMT, Andrew Bullock
<an*********************@ANDntlworldTHIS.com> wrote:
Is there a newer (better) way I should be doing this, or am I OK to be
using these?


You shouldn't use them because they're dangerous, though I don't
recall the details at the moment. There's no newer alternative way
either, you just have to use manual synchronization -- check for some
semaphore on the worker thread and go to sleep if it's set.
--
http://www.kynosarges.de

Feb 19 '06 #4

P: n/a

Using Suspend is not good idea, use ManualResetEvent as was suggested by
Christofer.
Moreover, Thread.Suspend() is obsolete in .NET 2.0

AB> I'm using a second thread within my program to do some long
AB> calculations, without locking up the UI:
AB>
AB> worker = new Thread(new ThreadStart(myClass.Run)); worker.Start();
AB>
AB> I want to be able to pause the calculating, so I'm using
AB>
AB> worker.Suspend()
AB> and
AB> worker.Resume()
AB> I'm not using any shared variables or such like resources which need
AB> to be protected/mutex but the compiler is telling me that these two
AB> commands are obsolete/depreciated, yet they both still function.
AB>
AB> Is there a newer (better) way I should be doing this, or am I OK to
AB> be using these?

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
Feb 19 '06 #5

P: n/a
On Sun, 19 Feb 2006 15:49:16 +0000 (UTC), Michael Nemtsev
<ne*****@msn.com> wrote:
Using Suspend is not good idea, use ManualResetEvent as was suggested by
Christofer.


Actually, that was Mark. :)'
--
http://www.kynosarges.de
Feb 19 '06 #6

P: n/a
Mark R. Dawson wrote:
<snip>

private void ProcessValues()
{
//Can run this anytime
for (int i = 0; i < 5; i++)
{
Console.WriteLine("processing:" + i);
}

//make sure I am allowed to keep going
this.waitHandle.WaitOne();

//Can only run this once main thread is happy
for (int i = 0; i < 5; i++)
{
Console.WriteLine("last processing:" + i);
}
}
}
}

Hi,

OK cool, thanks for your reply and the informative code! Very useful!

A question though, how does the thread "pause" while it's waiting for
the autoresetevent? It it in a busy-wait loop or is the thread blocked?

I also take it from the way this line:

this.waitHandle.WaitOne();

is actually explicitly written into the worker at a certain point, that
you cant just pause a thread at any point?

In my current use of wanting to pause threads, there are no critical
sections etc. I simply have a UI where you adjust some settings then
press go. The second thread goes away and does some large calculation. I
only wanted to be able to pause the thread because the calculation takes
some serious power and using other apps in the meantime is a pain.
Indeed the calculation is a loop, so i could place:
this.waitHandle.WaitOne();
in it, but pressing pause wouldn't necessarily have immediate effect
(depending on which part of the loop it was at when pause was pressed)

In this case, is .suspend() actually dangerous?

Thanks

Andrew
Feb 19 '06 #7

P: n/a
Mark R. Dawson wrote:
Its always a good idea to try to know why you are not suppose to do
something, rather than just accepting a blanket statement, otherwise how do
you know when not to do it. Not looking into these things will lead to
comments like "Throwing Exceptions are expensive, don't ever throw them" or
"Never concatenate strings, always use a string builder" :-)

Mark.


Thanks for that little gem about strings ;)
Andrew
Feb 19 '06 #8

P: n/a
Hello Andrew,

The dangerous of Suspend is that it suspends the hardware thread, at whatever
position it is currently being executed.
If u suspend in the middle of the lock() {...} that lock won't be realized
till u resume the thread
Using event-based approach, as was recomended, u yourself put points where
thread could be suspended in the "safe" way.

Based on your description, why not to perform calculation based on the load
of CPU? Managed thread should check the load of CPU and raise priority of
calculating thread in case of idling, and reduce it if some apps is being
loaded

AB> In my current use of wanting to pause threads, there are no critical
AB> sections etc. I simply have a UI where you adjust some settings then
AB> press go. The second thread goes away and does some large
AB> calculation. I
AB> only wanted to be able to pause the thread because the calculation
AB> takes
AB> some serious power and using other apps in the meantime is a pain.
AB> Indeed the calculation is a loop, so i could place:
AB> this.waitHandle.WaitOne();
AB> in it, but pressing pause wouldn't necessarily have immediate effect
AB> (depending on which part of the loop it was at when pause was
AB> pressed)
AB> In this case, is .suspend() actually dangerous?
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
Feb 19 '06 #9

P: n/a
Hi Andrew,
calling Wait on the WaitHandle puts the thread into the SleepWaitJoin
state, so it is not a busy-wait loop.

You are correct, using the wait handle will not have an immediate affect
on the thread, but only when it hits the line which asks if it is allowed to
proceed. I would suggest that maybe the background thread that you are using
to process is put on a lower than normal priority so that you are still able
to use other apps in the mean time. As you mention try to break the
processing down into discrete sections so that you are able to suspend at
minimal intervals.

Again, I would recommend against using Suspend in general, it is
considered bad practice, hence microsoft putting these methods as obsolete,
however if you know the ins and outs of your code then using it for simple
cases will not be dangerous but that is upto you.

Maybe others have different feeling on this?

Hope that helps
Mark Dawson
--
http://www.markdawson.org
"Andrew Bullock" wrote:
Mark R. Dawson wrote:
<snip>

private void ProcessValues()
{
//Can run this anytime
for (int i = 0; i < 5; i++)
{
Console.WriteLine("processing:" + i);
}

//make sure I am allowed to keep going
this.waitHandle.WaitOne();

//Can only run this once main thread is happy
for (int i = 0; i < 5; i++)
{
Console.WriteLine("last processing:" + i);
}
}
}
}

Hi,

OK cool, thanks for your reply and the informative code! Very useful!

A question though, how does the thread "pause" while it's waiting for
the autoresetevent? It it in a busy-wait loop or is the thread blocked?

I also take it from the way this line:

this.waitHandle.WaitOne();

is actually explicitly written into the worker at a certain point, that
you cant just pause a thread at any point?

In my current use of wanting to pause threads, there are no critical
sections etc. I simply have a UI where you adjust some settings then
press go. The second thread goes away and does some large calculation. I
only wanted to be able to pause the thread because the calculation takes
some serious power and using other apps in the meantime is a pain.
Indeed the calculation is a loop, so i could place:
this.waitHandle.WaitOne();
in it, but pressing pause wouldn't necessarily have immediate effect
(depending on which part of the loop it was at when pause was pressed)

In this case, is .suspend() actually dangerous?

Thanks

Andrew

Feb 19 '06 #10

P: n/a
Hi,

Thanks for everyones response :)

lots of knowledge gained ;)
Regards,

Andrew
Feb 19 '06 #11

P: n/a
Andrew Bullock <an*********************@ANDntlworldTHIS.com> wrote:

<snip>
Is there a newer (better) way I should be doing this, or am I OK to be
using these?


Others have suggested using ManualResetEvent. There's also
Monitor.Wait/Pulse, which is similar. It's less flexible than
ManualResetEvent, but I think it would be fine for what you're doing.
(It's a bit more efficient in .NET than ManualResetEvent, in my
experience, but that's unlikely to be an issue for you.)

See http://www.pobox.com/~skeet/csharp/t...eadlocks.shtml (half
way down the page) for more explanation and some sample code.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 19 '06 #12

P: n/a

"Mark R. Dawson" <Ma*********@discussions.microsoft.com> wrote in message
news:40**********************************@microsof t.com...
Its always a good idea to try to know why you are not suppose to do
something, rather than just accepting a blanket statement, otherwise how
do
you know when not to do it. Not looking into these things will lead to
comments like "Throwing Exceptions are expensive, don't ever throw them"
or
"Never concatenate strings, always use a string builder" :-)


How about: "Because they are deprecated methods!"
Feb 20 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.