View RSS Feed

code_glitch

Multithreading - A world of hurt

Rate this Entry
So you'd think multithreading is hard, until you get the baseline multithreaded console application, and then its easy. Untill you delve deeper into actually integrating it into some useful code and the it isn't...

Multithreading: dum all the engine's stuff into its thread and let that do constant housekeeping while you write your game code - perfect. Or not really: turns out that my initial fear of two threads accessing the same memory address at the same time is invalid, or rather misplaced. It has some truth: synchonysis. I saw that on my first live particle effect demo app. My main code hadn't finished drawing all the particles they were already on screen! And then they were gone at the same time when the engine thread decided it was going to clear for a re-draw. Hmm...

All that aside, I've now spent 3 hours burning the midnoght oil and beyond (now 3:32 AM) with an end in sight. Its all synchronized thanks to a single procedure called at the end that tells the thread something like, all data is drawn, you may now handle the video data and we will wait for you to finish instead of letting it handle my windows and etc...

All in all its quite nice, I cal one procedure once every game cycle, it handles the window, flipping, events (updates a variable to check later), keeps my FPS stable and lets me get on with whats what.

However, there is 1x weird occurence: it ignore the last draw. Seriously. I don't know if it's to do with render code or the multithreading but hey thats the way it is. And calling
Code:
glClear(GL_COLOR_BUFFER_BIT);
from within the thread has no effect

So far so good though, I have a standard procedure that does that for all game modes. If there is any interest in this, I might add it to Prometheus, but its a royal pain. Now implementing a random 'dummy' draw before the thread so it all works - its cheating I know but voila.

cheers,
code_glitch.

Submit "Multithreading - A world of hurt" to Digg Submit "Multithreading - A world of hurt" to del.icio.us Submit "Multithreading - A world of hurt" to StumbleUpon Submit "Multithreading - A world of hurt" to Google

Tags: None Add / Edit Tags
Categories
Uncategorized

Comments

  1. Murmandamus's Avatar
    You have to be very careful with multithreading and API/library calls. Many libraries are not "thread-safe", and can do anything from work perfectly 9,999 times out of 10,000, to turn your cat plaid. You also have to make sure that YOUR code is "thread-safe" as well, and also learn when and how to use various synchronized-access resources (mutexes, semaphores, spinlocks, critical sections, etc) to serialize access to shared code and data structures.

    It is exhilarating when it works, and maddening when it doesn't. My main forte' is multithreaded networking and file I/O. I am studying graphics libraries and APIs to see where multithreading can possibly be used, but so far, it's been a mixed bag because most graphics work is REALLY not "thread-safe". Generally, games (and graphics applications in general) keep the rendering to a single thread, with the exception of some of the "big guys".
  2. XProger's Avatar
    wglShareLists