[SDL] how to detect if a thread is still running
linux_dr at yahoo.com
Tue Jul 23 16:04:01 PDT 2002
--- Neil Bradley <nb at synthcom.com> wrote:
> > > > bool IsCalculateThreadAboutToExit = true;
> > > > return (!IsCalculateThreadAboutToExit);
> > > I realize this is only an example, but with the
> > > "IsThreadStillRunning"
> > Umm... IsThreadStillRunning() is simply an
> > 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
> > said nothing about WHEN he was quereing the status
> > 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. ;-)
Yup!... my bad... :(
> > does have to be quereied, but it's stupid to
> > that the main thread won't be doing something
> else, or
> > that the latency required must be so low that the
> > 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)
> while (IsThreadRunning)
> 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...
> > There are better
> > methods than polling a variable, but most games
> > is used primarily for games) have main-loops, and
> > these main loops can be used for this type of
> > in situations that don't require low latency.
> If it's spin locking on the variable, it uses CPU
> time - unnecessarily.
Most games are perpetually in game loops which often
look like this:
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... 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.
> > Typically threads should not be used where
> > 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
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. If
you're writting a server, whose whole life is going to
revolve around waiting for input, and responding to
it, then your point makes a good deal of sense, but
when the main loop has more to worry about than the
status of some threads and some I/O, it doesn't seem
> > > to use a thread, but there are so few
> > > needed that when someone says they need a thread
> > > than not they don't!
> > I agree that I have seen threads abused in many
> > instances, but they do have their place...
> > 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*." ;-)
Yes, I thought that was quite clever also...
Do You Yahoo!?
Yahoo! Health - Feel better, live better
More information about the SDL