Re: Context switching woes

[Steve Baker <sjbaker1@airmail.net>]

Mark Collins wrote:

> When the renering thread is actually doing something, I don't want the logic
> thread to feed data to the scenegraph API, to prevent items moving
> mid-render, and screwing everything up.

But surely you put the positional data into a double-buffer so that
the render thread picks up all the changes synchronously?

Then the two threads can happily work in parallel.

> Writing a simple lock mechanism
> would work fine on a single processor, but if the game is run on a
> multi-processor system, who knows what the scheduler is doing.

A properly implemented Djikstra semaphore mechanism will work fine on a
multiprocessor system.  I use them on a 48 CPU machine we have at work.

Check out semget/semctl/semop

> Under Windoze, you can tell the scheduler to give the current thread all
> access (i.e. don't change the context at all). While this has some drawbacks
> (it freezes all the other threads), it does make coding thread-safe
> functions a lot easier.

"some drawbacks"!!! You aren't kidding!  That's the kind of thinking that
gets you computers that crash and lock up a lot....now where did you say
you were getting this code from?  :-)

Maybe the reason M$ were so unexpectedly happy to have you rip their code
is that they know this would endow Linux with one of Windoze's more
'dangerous' features!

> Changing the priority of the threads will still allow the scheduler to
> change the context (i think).

Yes - you are certainly correct about that.  It would fail (for example)
if your rendering thread hit a block of some kind (eg the input buffer
of your graphics device filled up - or you tried to do disk I/O in order
to page in a texture map). If the running process is blocked then the
scheduler will run a lower priority task while your renderer was blocked
...which is precisely what you want it to do in order to make best use
of the CPU time.
 
Well, good luck getting the kernel guys to accept a patch like this.
I don't think Linus would "smile on it".  You might want to talk to
them in advance before you spend much time working on it.  I guarantee
they understand the issues *far* better than either you or I.

Plus you'd only be able to run the game on machines with your patched
kernel - it's not generally considered good form to say:

  HOW TO INSTALL YOUR GAME:

    1) First recompile the kernel with the following patch...

I think you should use thread-safe data buffering to allow both threads
to run concurrently and/or asynchronously - then crank up the priority
of the renderer so that it gets to run *FAST*.

My games tend to be single-threaded (because so few computers have
multiple CPU's) - but at work, our simulators run on computers with
dozens of CPU's and hundreds of threads - and trust me, it can be
done with the well-chosen set of features in a UNIX/Linux kernel.

(Doubly so under Linux - which has by far the fastest task-switch
time of any OS on the planet).

-- 
Steve Baker   HomeEmail: <sjbaker1@airmail.net>
              WorkEmail: <sjbaker@link.com>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net



---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.dk
For additional commands, e-mail: linuxgames-help@sunsite.dk