Thread.Suspend and Thread.Resume in Framework 2.0

[Buddy Home]

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,

 

[Larry Smith]

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

 

[Chris Mullins]

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

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.

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.

 

[Duggi]

Hi

I do not see any advantage of moving start, stop, suspend, resume a
thread to a separate class. They are in a single class already and are
static.... what else you need..

Thanks
-Srinivas.

 

[Larry Smith]

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).

 

[Buddy Home]

Let me get my point out.

I'm aware that it's bad design to suspend and pause the thread but I've got
a task to convert the code from Framework 1.0 to 2.0 and I was trying to get
rid of all the obsolete warning messages in the code. There are approx 200
warnings which call Suspend, Resume and Abort methods of the thread class. I
don't really have the time in my project plan to rewrite all this code so I
was looking for a generic approx which is why I showed the snippet code in
my original post.

Thanks,

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

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,

 

[Buddy Home]

Let me get my point out.

I'm aware that it's bad design to suspend and pause the thread but I've got
a task to convert the code from Framework 1.0 to 2.0 and I was trying to get
rid of all the obsolete warning messages in the code. There are approx 200
warnings which call Suspend, Resume and Abort methods of the thread class. I
don't really have the time in my project plan to rewrite all this code so I
was looking for a generic approx which is why I showed the snippet code in
my original post.

Thanks,