Thread.Suspend and Thread.Resume in Framework 2.0

sign of poor engineering? Please explain.

>Why do you need to suspend and resume threads in your app? Could that be
a
sign of poor engineering? Please explain.

While "suspending " a thread in the traditional manner has been deprecated
by MSFT, "pausing" a thread between atomic operations (under the
developer's control) is certainly a legitimate requirement :)

Hello,

I want to understand whats the best way to write code to replace
Thread.Suspend, Thread.Resume and Thread.Abort.

I have lots of code calling these existing methods and want to minimize the
risk of changing the code everywhere so here is what I think I could do,
which is to create my own ThreadWrapper class which inherits from Thread and
which has these three methods already defined but does it a different way
and then my original code can work as normal by just referencing my
ThreadWrapper class.

Example

public class ThreadWrapper : Thread
{
public void Abort()
{
// What do i do here
}
public void Suspend()
{
// What do i do here
}
public void Resume()
{
// What do i do here
}
}

My App
public class Test
{
static void Main(string[] args)
{
ThreadWrapper tw = new ThreadWrapper() ;
...
tw.Suspend();
tw.Resume();
tw.Abort();
}
}
Thanks,

manually freezing and thawing threads, I would kick it back to the
developer and tell him to re-write it. He would have to come back with a
VERY strong reason why he's doing it.

The standard thread synchronization mechanisms are pretty rich - monitor /
mutes / semaphore / rwlock / event / Interlocked. Other than debugging
scenarios, I don't see the need to externally start/stop threads very
often.

Why do you need to suspend and resume threads in your app? Could that be a
sign of poor engineering? Please explain.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Buddy Home" wrote:

>Hello,

I want to understand whats the best way to write code to replace
Thread.Suspend , Thread.Resume and Thread.Abort.

I have lots of code calling these existing methods and want to minimize
the
risk of changing the code everywhere so here is what I think I could do,
which is to create my own ThreadWrapper class which inherits from Thread
and
which has these three methods already defined but does it a different way
and then my original code can work as normal by just referencing my
ThreadWrappe r class.

Example

public class ThreadWrapper : Thread
{
public void Abort()
{
// What do i do here
}
public void Suspend()
{
// What do i do here
}
public void Resume()
{
// What do i do here
}
}

My App
public class Test
{
static void Main(string[] args)
{
ThreadWrapper tw = new ThreadWrapper() ;
...
tw.Suspend();
tw.Resume();
tw.Abort();
}
}
Thanks,

>I don't think that's really legit - if I were to see code that was
manually freezing and thawing threads, I would kick it back to the
developer and tell him to re-write it. He would have to come back with a
VERY strong reason why he's doing it.

I'm glad I don't work for you :)

>The standard thread synchronization mechanisms are pretty rich - monitor
/ mutes / semaphore / rwlock / event / Interlocked. Other than debugging
scenarios, I don't see the need to externally start/stop threads very
often.

Of course you apply proper synchronization techniques when required. And
you certainly don't pause a thread as a means of synchronization . You use
one of the techniques you cited. If a user clicks the "Cancel" button to
abort a background operation however (for example), and you then display a
"confirm cancellation" dialog for the user, normally you'll want to signal
a "pause" event so the background thread can temporarily suspend itself
until the user exits the dialog (the thread will respect the "pause" event
by periodically testing for it).