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

The sin of Suspend()

P: n/a
Hi all!

I'm working on an application that due to the nature of the application
is heavily concurrent. Usually, there will be between 15 and 20 threads
running at the same time. However, at some times it might be necessary
to pause execution of these threads. Thread.Suspend() looks like an
excellent candidate, but the method is deprecated in the framework.
According to the documentation I should use dedicated objects like
Monitors for synchronization.

I do understand why using Suspend() for synchronization is a Bad Idea
(TM). But is it a bad idea for pausing (parts of) an application as
well? There is no way of telling which part of the code each thread is
executing and I would hate to have to litter my code with checkPaused()
methods, or something like that.

Does anyone know whether it is a sin to use Suspend() in this case and
why or why not?

Thanks in advance,
Bram Fokke
the Netherlands

Mar 28 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
As long as you are absolutely sure that one thread does not eat the same
piece of memory as another thread, both in managed code and below the
surface, suspend is not that wicked. It is deprecated largely because most
people only examined the surface and ignored what was going on below the
surface.

If you go this route, note that your code is not considered thread safe.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
"b.*****@gmail.com" wrote:
Hi all!

I'm working on an application that due to the nature of the application
is heavily concurrent. Usually, there will be between 15 and 20 threads
running at the same time. However, at some times it might be necessary
to pause execution of these threads. Thread.Suspend() looks like an
excellent candidate, but the method is deprecated in the framework.
According to the documentation I should use dedicated objects like
Monitors for synchronization.

I do understand why using Suspend() for synchronization is a Bad Idea
(TM). But is it a bad idea for pausing (parts of) an application as
well? There is no way of telling which part of the code each thread is
executing and I would hate to have to litter my code with checkPaused()
methods, or something like that.

Does anyone know whether it is a sin to use Suspend() in this case and
why or why not?

Thanks in advance,
Bram Fokke
the Netherlands

Mar 28 '06 #2

P: n/a
<b.*****@gmail.com> wrote:
I'm working on an application that due to the nature of the application
is heavily concurrent. Usually, there will be between 15 and 20 threads
running at the same time. However, at some times it might be necessary
to pause execution of these threads. Thread.Suspend() looks like an
excellent candidate, but the method is deprecated in the framework.
According to the documentation I should use dedicated objects like
Monitors for synchronization.

I do understand why using Suspend() for synchronization is a Bad Idea
(TM). But is it a bad idea for pausing (parts of) an application as
well? There is no way of telling which part of the code each thread is
executing and I would hate to have to litter my code with checkPaused()
methods, or something like that.

Does anyone know whether it is a sin to use Suspend() in this case and
why or why not?


If there is no way to tell where each of the threads are, it sounds
like a really bad idea to call Suspend. What if one of the threads owns
a lock which the other threads need? What if they're half way through
modifying some shared data, leaving it in an inconsistent state?

Is there really no point in your code which is executed sufficiently
regularly that it would make a good point to check for pausing?

--
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
Mar 29 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.