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?

[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]

"Martin Maat [EBL]" <du***@somewher e.nl> wrote:

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

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

[C# Learner]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote:

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.Threadin g.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.
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.

[C# Learner]

C# Learner <cs****@learner .here> wrote:

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.

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

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]

"Martin Maat [EBL]" <du***@somewher e.nl> wrote:

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.

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

http://msdn.microsoft.com/library/de...thodsTopic.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]

"Martin Maat [EBL]" <du***@somewher e.nl> wrote:

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

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.

:-)

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.

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

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/de...thodsTopic.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/de...abledtopic.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]

"Martin Maat [EBL]" <du***@somewher e.nl> wrote:

>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/de...thodsTopic.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/de...abledtopic.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/en...asp?frame=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.

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!