gamedevlists-windows

[GD-Windows] Stopping a thread cleanly

[Brian H. <bri...@py...>]

Okay, kind of a newbie question, but I thought I understood it, now I'm
not so sure.

What are the advantages/disadvantages of exiting a thread based on
WaitForSingleObject with short timeout vs. checking a global variable?
Both are effectively in a delayed hard polling loop, where the delay is
a Sleep( 250 ).

The only advantage I can really see is that the WFSO call is going to
avoid race conditions intrinsically, whereas checking a global variable
I'll have to be a lot more diligent about guarding accesses to the
variable.

Brian

RE: [GD-Windows] Stopping a thread cleanly

[Jon W. <hp...@mi...>]

The global variable doesn't enter the kernel, whereas the wait 
call does. On the other hand, if the thing is already held, then 
spinning and polling for your entire quanta isn't going to help 
much.

Which specific kind of synchronization are you doing here? I've 
found the Windows critical section to be very efficient, as it 
will not enter the kernel if there isn't contention, and it will 
do some number of spins in user space before entering the kernel 
if you're on a multi-CPU machine, under contention (exactly how 
many is detemined by you). The idea being that if you guard some 
simple operation like manipulating a list head/tail, then a 
thousand spins is likely to make the critical section available, 
and is a lot quicker than entering the kernel.

Sleep is also likely to enter the kernel, and thus is not very 
efficient. Remember that the time quanta is measured in milliseconds 
(actually, the "foreground time slice" can get closer to a hundred 
milliseconds) so anything "spinning" is bad if it's likely to be 
under contention. On the other hand, entering the kernel is also 
bad, because it's likely to cause death by context switching.

Cheers,

				/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Sunday, February 17, 2002 11:37 AM
> To: gam...@li...
> Subject: [GD-Windows] Stopping a thread cleanly
> 
> 
> Okay, kind of a newbie question, but I thought I understood it, now I'm
> not so sure.
> 
> What are the advantages/disadvantages of exiting a thread based on
> WaitForSingleObject with short timeout vs. checking a global variable?
> Both are effectively in a delayed hard polling loop, where the delay is
> a Sleep( 250 ).
> 
> The only advantage I can really see is that the WFSO call is going to
> avoid race conditions intrinsically, whereas checking a global variable
> I'll have to be a lot more diligent about guarding accesses to the
> variable.
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

RE: [GD-Windows] Stopping a thread cleanly

[Jon W. <hp...@mi...>]

> What are the advantages/disadvantages of exiting a thread based on
> WaitForSingleObject with short timeout vs. checking a global variable?

Someone should teach me to not mis-read other people's 
questions. ;-)

You have a worker thread, and it's gotten time to shut it down? 
Somehow, you're giving this worker thread instructions, so I'd 
suggest sending a shutdown message the same way you send other 
commands to the thread.

I think that either suggestion you have (wait on an object with 
a time-out, versus sleeping) are sub-optimal, because they're 
polling. Instead, you might want to block (for real) on some 
primitive until there is work to do, and make sure that primitive 
gets signalled once work is put in. You may find it easier to 
use a condition variable for this set-up.

Once it's time to exit the thread, you simply set a global (or 
queue a command, or whatever) and wake the thread up; it'll wake 
up and notice there's a quit condition (without re-entering the 
kernel) and go away.

If the worker thread is supposed to asynchronously "pick up" work 
every so often (sometimes necessary) then you should use the time-
out on the wait operation as your throttle for when to look for 
more work. That way, you can signal this event (or whatever) when 
it's time to exit, and the thread will immediately wake up and 
exit, instead of you having to wait for however long the sleep 
operation would take. You can even use the condition of "waiting 
for this object did NOT return time-out" as your exit condition, 
for a race condition free way of doing it :-)

Finally, the most dangerous thing with exiting threads is having 
other threads wait for those threads; unless you design carefully, 
it's very easy to get into deadlock that way...

Cheers,

				/ h+

Re: [GD-Windows] Stopping a thread cleanly

[Andrew G. <an...@ra...>]

It's just 'better' really. One case that I can remember is this:


int ThreadFunc()
{
    while (false == bExit)
    {
    }
}

In this case the compiler could put bExit in a register due to optimisation
which obviously isn't good. You could specify it as volatile which will
prevent that, but that seems a bit ugly.

And you have the cases where the compiler might rearrange the order of

bExit=false;
CreateThread();

// andrew

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Sunday, February 17, 2002 7:37 PM
Subject: [GD-Windows] Stopping a thread cleanly


> Okay, kind of a newbie question, but I thought I understood it, now I'm
> not so sure.
>
> What are the advantages/disadvantages of exiting a thread based on
> WaitForSingleObject with short timeout vs. checking a global variable?
> Both are effectively in a delayed hard polling loop, where the delay is
> a Sleep( 250 ).
>
> The only advantage I can really see is that the WFSO call is going to
> avoid race conditions intrinsically, whereas checking a global variable
> I'll have to be a lot more diligent about guarding accesses to the
> variable.
>
> Brian
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>