Creating a Pause in Execution

[C# Learner]

What's a nice way to create a non-blocking pause in execution?

Will I need to use some kind of timer for this, or is there a nicer
way?

 

[Vadym Stetsyak]

int pauseTime = 2000;
System.Threading.Thread.Sleep(pauseTime);

 

[C# Learner]

int pauseTime = 2000;
System.Threading.Thread.Sleep(pauseTime);

Hi Vadym, thanks for your quick response.

The problem with that is - it blocks the current (GUI) thread. I'm
looking for something that will do this without blocking the current
thread.

Regards

 

[Jon Skeet [C# MVP]]

The problem with that is - it blocks the current (GUI) thread. I'm
looking for something that will do this without blocking the current
thread.

What *exactly* are you trying to pause then? If it's another thread,
just make that other thread sleep instead.

 

[Mark mm]

Hi Vadym, thanks for your quick response.

The problem with that is - it blocks the current (GUI) thread. I'm
looking for something that will do this without blocking the current
thread.

Regards

You'll have to use a separate thread for the GUI and the thing you want
to pause then use Vadym's solution. At first I wasn't sure what you
meant by non-blocking, in relation to other programs or within your
program,

 

[C# Learner]

What *exactly* are you trying to pause then? If it's another thread,
just make that other thread sleep instead.

Let me clarify...

My GUI app has only a single thread. I would like to create a pause
in execution without blocking this single thread.

Right now I'm using a timer to do this:

private void Foo()
{
delayTimer.Start();
}

private void delayTimer_Tick(object sender, System.EventArgs e)
{
delayTimer.Stop();
DoSomething();
}

The effect here is that DoSomething() is called after a short delay.

Now, this works fine, but I was wondering if there's a nicer method of
doing this.

Thanks

 

[Jon Skeet [C# MVP]]

Let me clarify...

My GUI app has only a single thread. I would like to create a pause
in execution without blocking this single thread.

I still don't understand what you really mean by a "pause" then. A
pause has to occur in *some* thread...

Right now I'm using a timer to do this:

private void Foo()
{
delayTimer.Start();
}

private void delayTimer_Tick(object sender, System.EventArgs e)
{
delayTimer.Stop();
DoSomething();
}

The effect here is that DoSomething() is called after a short delay.

Now, this works fine, but I was wondering if there's a nicer method of
doing this.

That sounds like it's basically another thread (a threadpool thread)
which is then calling back to your event handler. (I don't know whether
it's a System.Windows.Forms.Timer or a System.Threading.Timer though.)

That's basically what you need though - it's not what I'd describe as a
pause though, so much as scheduling something to occur at some point in
the future. You're not actually *pausing* anything, as far as I can
see.

 

[Martin Maat [EBL]]

What *exactly* are you trying to pause then? If it's another thread,
just make that other thread sleep instead.

I think he wants to make the main thread to go to sleep for a number of
seconds yet wake up and service GUI events as they occur, then get back to
sleep at the point it was initially laid to bed and wait for the remaining
time to be waken up by the alarm set when it was first put to sleep. Just
getting a grip on threads I guess .

I agree, he should explain the problem, someone will post a solution and
threads will make more sense to him.

Coming from a non-threaded background this is the way you think, I can
relate to that. In the old days we used to keep our system responsive by
doing our "background processing" on the one main thread in a loop, calling
Application.ProcessMessages or the equivalent of that every x iterations so
the user could abort the operation by pressing a button that raised a flag
that would make the code leave the loop.

Martin.

 

[C# Learner]

I think he wants to make the main thread to go to sleep for a number of
seconds yet wake up and service GUI events as they occur, then get back to
sleep at the point it was initially laid to bed and wait for the remaining
time to be waken up by the alarm set when it was first put to sleep. Just
getting a grip on threads I guess .

I agree, he should explain the problem, someone will post a solution and
threads will make more sense to him.

I'm just thinking to make a simple pause without going to the extra
effort of writing and maintaining a seperate thread. Sure, I know how
this could be implemented with an extra thread, but I really want a
simple and neat solution here.

Never mind - I'll stick with the timer.

Coming from a non-threaded background this is the way you think, I can
relate to that. In the old days we used to keep our system responsive by
doing our "background processing" on the one main thread in a loop, calling
Application.ProcessMessages or the equivalent of that every x iterations so
the user could abort the operation by pressing a button that raised a flag
that would make the code leave the loop.

I've seen a lot of recent code that does this, believe it or not!
It's almost an abuse of the CPU.

 

[C# Learner]

I'm just thinking to make a simple pause without going to the extra
effort of writing and maintaining a seperate thread. Sure, I know how
this could be implemented with an extra thread, but I really want a
simple and neat solution here.

Okay, so "pause" was a bad choice of word here. I'm thinking of
"pause" from a high-level -- from the user's perspective.

 

[Martin Maat [EBL]]

My GUI app has only a single thread. I would like to create a pause

in execution without blocking this single thread.

If we take this literally it is impossible, contradictary in itself. But if
lagged execution of a command is really what you are after your solution is
effective, efficient and elegant.

The only application I can think of is an OS/2 or Linux GUI simulator.
"Sluggish responsiveness for Windows". Might that be what you are making?
.

Martin.

 

[C# Learner]

If we take this literally it is impossible, contradictary in itself. But if
lagged execution of a command is really what you are after your solution is
effective, efficient and elegant.

The only application I can think of is an OS/2 or Linux GUI simulator.
"Sluggish responsiveness for Windows". Might that be what you are making?
.

I can't speak for OS/2 'coz I've never used it, but I find GNU/Linux
faster in general (on this box) that Win XP.

Anyway...

I'm making a simple game in which the human makes his/her move, then
the computer opponent makes "his/her" move after a slight delay.

 

[C# Learner]

That sounds like it's basically another thread (a threadpool thread)
which is then calling back to your event handler. (I don't know whether
it's a System.Windows.Forms.Timer or a System.Threading.Timer though.)

It's a System.Windows.Forms.Timer timer. Hmm... I might look into
using one of the other two timers, as this one is eligable for garbage
collection when it's disabled. Can't be good for this app - it's
starting a stopping a lot.

 

[C# Learner]

It's a System.Windows.Forms.Timer timer. Hmm... I might look into
using one of the other two timers, as this one is eligable for garbage
collection when it's disabled.

I'm presuming that means the Win32 timer this object wraps around.

 

[Martin Maat [EBL]]

It's a System.Windows.Forms.Timer timer. Hmm... I might look into

using one of the other two timers, as this one is eligable for garbage
collection when it's disabled. Can't be good for this app - it's
starting a stopping a lot.

As long as your timer component does not run out of scope it will not be
garbage collected, I see no need to worry there.

Furthermore, I am not absolutely sure about how this particular timer
component is implemented but its behavior suggests it is the good old 18.2
times a second interupt based timer. I do not expect a separate thread to be
living in the timer component. Every 0.054 seconds your timer gets a chance
to check if the interval has elapsed and if it has the component will post a
message to your form which is handled by your main thread like any other UI
event and dispatched to your timer event handler. In a GUI application you
cannot get more efficient than that.

Martin.

 

[Martin Maat [EBL]]

The only application I can think of is an OS/2 or Linux GUI simulator.

I can't speak for OS/2 'coz I've never used it, but I find GNU/Linux
faster in general (on this box) that Win XP.

I installed Mandrake with KDE and it looks very nice, I don't want
to bash it in any way but I found it considerably less snappy than
Windows XP on the same box.

Anyway...
Indeed.

I'm making a simple game in which the human makes his/her move, then
the computer opponent makes "his/her" move after a slight delay.

I would use a timer in the same manner, seems like the way to go, no need to
mess with threads. I might add that if the computer's thinking is (or might
get as the app evolves) a heavy task that takes a bit of processing time,
you will need that thread anyway for determining the computer's next move.
And then I would say it would be better to start working on the response
right after the human made his move and then either make the computed move
straight away or, if the result would be available before the minimum lapse,
sleep until the minimum lapse has passed. That way you would not waste any
time.

Martin.

 

[C# Learner]

As long as your timer component does not run out of scope it will not be
garbage collected, I see no need to worry there.

I wouldn't have been concernced here, but then I read this:

http://msdn.microsoft.com/library/d.../frlrfSystemWindowsFormsTimerMethodsTopic.asp

"A timer that is disabled is subject to garbage collection."

I wonder what this means exactly.

Furthermore, I am not absolutely sure about how this particular timer
component is implemented but its behavior suggests it is the good old 18.2
times a second interupt based timer. I do not expect a separate thread to be
living in the timer component. Every 0.054 seconds your timer gets a chance
to check if the interval has elapsed and if it has the component will post a
message to your form which is handled by your main thread like any other UI
event and dispatched to your timer event handler. In a GUI application you
cannot get more efficient than that.

I expect it to work like this too.

Martin.

Regards

 

[C# Learner]

I installed Mandrake with KDE and it looks very nice, I don't want
to bash it in any way but I found it considerably less snappy than
Windows XP on the same box.

I'm a Mandrake user myself.

I would use a timer in the same manner, seems like the way to go, no need to
mess with threads. I might add that if the computer's thinking is (or might
get as the app evolves) a heavy task that takes a bit of processing time,
you will need that thread anyway for determining the computer's next move.
And then I would say it would be better to start working on the response
right after the human made his move and then either make the computed move
straight away or, if the result would be available before the minimum lapse,
sleep until the minimum lapse has passed. That way you would not waste any
time.

Well, in this app, the computer's thinking is so simple that its move
would be made more or less *immediately* after the human's move, so I
don't have to concern myself with the above.

Martin.

Thanks Martin.

 

[Martin Maat [EBL]]

As long as your timer component does not run out of scope it will not be

I wouldn't have been concernced here, but then I read this:

http://msdn.microsoft.com/library/d.../frlrfSystemWindowsFormsTimerMethodsTopic.asp

"A timer that is disabled is subject to garbage collection."

I don't find that statement behind the link. The same message in different
words is here though:

http://msdn.microsoft.com/library/d...fsystemwindowsformstimerclassenabledtopic.asp

"The timer is not subject to garbage collection when the value is true."

I wonder what this means exactly.

I would think this simply means there is some lazy initialization and
agressive cleanup going on within the timer object which is after all a
wrapper around a system timer. Since system timers are a limited resource
and you are not really using the system timer while the component's Enabled
property is set to false it can be released. As soon as you enable it again
you will get a new one on the fly. To you as a client it makes no
difference. I cannot imagine that the wrapping timer component you have on
your form will be spontaniously garbage collected while you are holding a
reference to it. The choice of words in the ducumentation may be
unfortunate.

I am making this up though, I too am getting curious about the true meaning
of the statement.

Martin.

 

[C# Learner]

I don't find that statement behind the link. The same message in different
words is here though:

http://msdn.microsoft.com/library/d...fsystemwindowsformstimerclassenabledtopic.asp

"The timer is not subject to garbage collection when the value is true."

Sorry, the correct link should have been:

http://msdn.microsoft.com/library/e...indowsFormsTimerClassStopTopic.asp?frame=true

I would think this simply means there is some lazy initialization and
agressive cleanup going on within the timer object which is after all a
wrapper around a system timer. Since system timers are a limited resource
and you are not really using the system timer while the component's Enabled
property is set to false it can be released. As soon as you enable it again
you will get a new one on the fly. To you as a client it makes no
difference. I cannot imagine that the wrapping timer component you have on
your form will be spontaniously garbage collected while you are holding a
reference to it. The choice of words in the ducumentation may be
unfortunate.

I am making this up though, I too am getting curious about the true meaning
of the statement.

The bit that throws me is that it says that the "timer" is subject to
garbage collection when disabled. Ambiguous...

Martin.

Thanks for your thoughts!