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

Neil Bradley nb at synthcom.com
Tue Jul 23 15:26:01 PDT 2002


> > > bool IsCalculateThreadAboutToExit = true;

> > >   return (!IsCalculateThreadAboutToExit);
> > I realize this is only an example, but with the
> > "IsThreadStillRunning"
> Umm... IsThreadStillRunning() is simply an accessor.
> It doesn't loop, or anything like that...

True... the "return" I read as a "while". I'm just wondering what the
calling thread is doing with it.

> The user
> wanted to know "is the other thread still running"...
> said nothing about WHEN he was quereing the status of
> the thread or HOW OFTEN.

Right, however rather than just answering the question, I'd like to pop up
a stack and understand how it is used before making a recommendation on
implementation. It may be that a global is all that's needed, but more
often than not (as you acknowledge), people tend to write code that spin
locks on a variable until it changes. Also, don't forget to declare it
volatile. ;-)

> does have to be quereied, but it's stupid to assume
> that the main thread won't be doing something else, or
> that the latency required must be so low that the main
> thread must busy-wait on it's value.

If more people "correctly" used threads (I.E. not spinning on
global variables or waking up every 10 milliseconds to check a variable)
then it certainly would be stupid, but gauging by the amount of code I've
seen that does stuff like:

	while (IsThreadRunning)

And:

	while (IsThreadRunning)
	{
		Sleep(10);
	}

I can't help but injerject that there are always better methods than this.

> There are better
> methods than polling a variable, but most games (SDL
> is used primarily for games) have main-loops, and
> these main loops can be used for this type of polling
> in situations that don't require low latency.

If it's spin locking on the variable, it uses CPU time - unnecessarily.

> Typically threads should not be used where extremely
> low latency is required.

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.
Spinlocking on a variable will not help. A Better way to reduce the
latency would be to have the main thread wait on a conditional variable,
and the subordinate thread do a conditional variable 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.

> > Andi t begs the question, if a
> > subordinate thread is spawned
> > off, only to be waited on by another thread, why was
> > the subordinate
> > thread created in the first place?
> Who said anything about what the main thread was
> doing?

That's why I said "if the subordinate thread"... I'm making an educated
guess based on past experiences that it's doing a spin lock, which isn't
good.

> > to use a thread, but there are so few circumstances
> > needed that when someone says they need a thread for
> > than not they don't!
> I agree that I have seen threads abused in many
> instances, but they do have their place... Especially
> for asynchronous data processing.

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*." ;-)

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