[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Context switching woes

> I don't want to change the priority, as that wouldn't solve my original
> problem. Here's what I', planning on doing.
> I might have 3 threads, one for logic, one for rendering and one for
> networking. (I may merge the logic and rendering threads if there is no easy
> solution to this problem).
> 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. 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.

this is what the mutex and semaphore facilities exist for. You might want to
do some reading on those two concepts. I'd do it with a mutex, and lock the
scenegraph inside of one, that way when one has critical section access, the
other will wait until it's freed. You can also poll mutex's so the thread won't stop
on a locked data chunk, it'll just skip it. All depends on how you want to
interface the scenegraph info (or other volatile data). There're lots of articles
on the web about those, the manpages are pretty decent, and lots of books
describe 'em. "mutex" and "semaphore". :)

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

ugh, what a hack solution


        -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep

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