[SDL] multithreaded programming

Miles Vignol mvignol at earthlink.net
Wed Nov 12 12:50:01 PST 2003


> > in general, i'd be looking at splitting off threads to perform
> > geometric operations on chunks of public data with the result being
> > more public data.  is that a nightmare waiting to happen?
>
> Depends on how you do it.
>
> Most people start a thread and expect that it will then run in parallel
> with the rest of your code. They expect it to share the processor on an
> equal basis. That is rarely what actually happens. Most of the time the
> thread that is running keeps running. The rule of thumb is that a thread
> will only run when no other thread *can* run.
>
> People seem to think that using threads will make their program run
> faster. No matter how many processors you have you can never get more
> than 100% of the available CPU cycles. So, if your code is currently
> spending a lot of time blocked and only uses a few percent of the CPU
> then adding threads can make it run faster. But only it they aren't also
> blocked.
>

bob, thanks for the pointers.  part of my rationale for multithreading is
that multi-processor systems would benefit (greatly?) from this technique.
but the other aspect is that i'm trying to figure out a nice scheme for
interrupting operations and a seperate thread that gets a signal sounds like
a potentially clean way of doing things.  rather than having to slap UI
checking code in my process loops, i'd like to just set up signal trapping
and have the main UI code run in a seperate thread from the processing code
to handle user interrupts and such.

this leads me to my next question.  obviously i'd rather tell a thread to
stop rather than just kill it with SDL_KillThread().  it would seem SDL
ought to have some means of sending signals to threads, but i haven't come
across any.  does the SDL_Thread handle have enough information to extract
the appropriate information to use OS specific signal handling?  is signal
handling pretty well cross platform?

thanks again,

-miles vignol





More information about the SDL mailing list