[SDL] how to detect if a thread is still running

Neil Bradley nb at synthcom.com
Tue Jul 23 16:25:59 PDT 2002


> > I can't help but injerject that there are always
> > better methods than this.
> I hear you, but this seems like giving each driver a
> disertaion on safe driving any time they visit the gas
> pump... Most people probably don't drive as safely as
> they could, but that probably won't help... People are
> unfortunately comfortable with their bad habbits
> despite good advice...

Yeah, I know. ;-( But there have been at least a couple of people who have
had their ways changed by a simple comment just because they didn't know
those options existed! Continuous self improvement... helping eachother is
a good thing, even if only a small percentage of the people who hear it
actually get it and internalize it!

> while(!AreWeExiting())
> {
>     CheckOnInputs();
>     CheckOnOtherStuff();
>     if(AreWeInFocus())
>     {
>         if(!IsGamePaused())
>         {
>             UpdateGame();
>         }
>         UpdateUI();
>         if(DidAnythingChange())
>         {
>             UpdateScreen();
>         }
>         if(DoWeHaveTimeToBurn())
>         {
>             Sleep(SomeTime);
>         }
>     }
>     else
>     {
>         Sleep(QuiteAWhile);
>     }
> }
> Or basically one giant spin-lock... it isn't super
> efficient, but alot of the things that cause it to
> Pause are generated by the main thread itself, and
> can't be signaled by the OS...

What you have above isn't so bad - due to the sleeps. That'll put the
thread to sleep, therefore relinquishing CPU time. I don't consider this a
spin lock since there isn't anything that spins inside a thread, and it
really is using the OS to sleep. Another alternative is to use a semaphore
and have a timer do a post to the semaphore, and the main loop to wake up
on that semaphore. Probably negligible differences between the approach
above and the semaphore approach.

> There may be better
> ways, but I haven't seen one that's general purpose
> enough to work with a full-blown game, and the gains
> are usually minimal compared to the status quo.

Checking on focus seems like something that could be completely eliminated
as a runtime check since messages are dispatched for switching focus. But
you're right - there isn't much in the way of improvement that could be
made. At least under DOS I could do controller input via interrupts so I'd
never check for any keys being pressed. I'd just get updates. ;-)

> > In preemptive OSes that are inherently unpredictable
> > (I.E. Linux, FreeBSD,
> > Windows, OS X), you're at the mercy of the OS's
> > scheduler anyway.
> > set and a delay of 0,
> > which will immediately exit that thread and give
> > other threads a chance to
> > run. This is a much faster approach than a spinlock
> > check.
> In theory, I agree.  In practice, this has one fatal
> flaw:  If the main thread is waiting on a conditional
> variable than it's "too busy" (or more accuratly "too
> asleep") to do anything useful, which defeats the
> whole purpose of having the separate thread.

Thank you for so eloquently supporting my prior statement of threads most
often shouldn't be used. ;-)

> > Oh yeah. My favorite "other thread" is for sound
> > processing in a game.
> > It's especially cool to see SDL have it as a
> > separate thread rather than
> > requiring the user to "push sound out the port
> > periodically". Immediately
> > in my mind when I saw this, I thought - "These SDL
> > guys *ROCK*." ;-)
> Yes, I thought that was quite clever also...

Been doing this in DOS land since '91! It's especially useful when doing
emulation of sound chips and whatnot - just write to the device and the
audio will get updated when it's needed. Seems so natural to be a separate
thread!

-->Neil

-------------------------------------------------------------------------------
Neil Bradley            What are burger lovers saying
Synthcom Systems, Inc.  about the new BK Back Porch Griller?
ICQ #29402898	        "It tastes like it came off the back porch." - Me






More information about the SDL mailing list