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
>