   Thread scheduling in Windows
  I'd like to have 2 threads in my game application, but to effectively control when those threads run (or at least one of the threads).I envision a background thread, and another thread or mechanism that may behave a lot like a timer interrupt.  This "interrupt" thread would interrupt the background thread a predetermined number of times per second.  This rate of interruption may need to change dynamically.What features and mechanisms in Windows are available to support such an approach, such that it works efficiently?  The goal is to let the background thread have all the CPU time it can while the "interrupt" thread is idle, instead of giving both threads equal billing even if the interrupt thread doesn't need it.The interrupt thread could be an interrupt function if necessary.  It would not need to be timesliced with the other thread, but could start as a function call and end as a function return.In detail, I plan to update the game world at a constant rate (20 Hz) in the background as a loop, while rendering frames much faster using an interrupting mechanism, with interpolation for smooth motion.   
  Well, I would suggest not using threads for this, since using them will mean you'll have to deal with all kinds of synchronization issues (although if you're already using threads for something else, then it might not be a bad idea to use them for this too; in which case, look at Using Waitable Timer Objects [MSDN])There are a couple of articles I've seen that show how to have a fixed update rate with a variable rate display rate, without using threads.One is Fix Your Timestep!Another is Instant Replay : Building a Game Engine with Reproducible Behavior (requires a gamasutra login; the relevant information is on the second page)I think they both use the same method though, so you might as well just read the first one unless you're particularly interested in making a replay system too.John B   ;  To cut right to the chase, what you ask can be done with Win32 fibers. Or in fact, you could just as well do it yourself without threading it at all.BUTThis sounds idiotic. I'm not entirely clear on why this needs to be threaded at all, and scheduling threads yourself is likely to perform worse than OS threads on any number of processors. Allow me to suggest an alternative. Make the renderer and the game updater real kernel threads. Additionally, double buffer your world state. The basic idea is that the rendering thread will render from the "front" buffer, applying interpolation as necessary, and running as fast as possible. The updater thread will work on the "back" buffer, setting the newest data there. When it's done it waits for the current frame to finish rendering, and then locks the rendering game state and copies the "back" data to it. Then it sleeps if it's running too fast, and loops.Things of note:Real scheduling of real kernel threads, which is likely to be far more efficient than any kind of custom user scheduling.No "stuttering" due to interruption by the updater, and this will probably work quite well on a dual core machine. Your idea won't utilize more than one core ever, from what I can figure.Double buffering mechanism neatly avoids any nasty dependencies or synchronization locks while still maintaining real threading.   ;Quote:Original post by PromitDouble buffering mechanism neatly avoids any nasty dependencies or synchronization locks while still maintaining real threading.You will still have to synchronize access when you do your "world"-flip.Happy coding.   ;Quote:Original post by LordShadeYou will still have to synchronize access when you do your "world"-flip.Of course, but it's a very simple and clean lock to do, and a comparatively fast operation.   ;  I appreciate the warnings against multithreading (advice I often give to others), but I've reached a limitation that I believe calls for this approach, so assume that there must be these 2 threads.Reason being I have a potentially massive world update every 50 ms for a large-scale simulation.  Now when the world update is brief I get the nice frame updating behavior below:__|__|__|__|__|__|__|__|__|__|__|__|__However when there are many many objects in the simulation world, I get the frame updating behavior below (currently a single thread):__|__|__|__|_______________________|__|__|__|_________________________|__|__|__|_______I still may be getting 80 FPS, but its a very erratic 80 FPS.My simulation has a tolerable 50 ms latency and other mechanisms (double-buffering, interpolation etc.) so that the game world can be updated without conflicting with the rendering, and motion is smooth.I've accounted for the complexities of multiple threads.  I'm just looking for the most effective ways to "schedule" the thread behavior if possible.  There may be several ways to skin such a cat to get the desired result, regardless of actual implementation.Maybe an occasional call to sleep() in the rendering thread is enough to schedule it nicely, allowing the world updating thread to get busy while the rendering thread sleeps.  I want to weigh all options though, and see if there are similar experiences with such a situation.  The more control over the threads the better. I'll look into fibers.  Threads in Windows is still a bit of a mystery to me though.If I had full hardware control I'd implement a variable rate timer interrupt for rendering, but we're in Bill's world now.Thanks for the advice, and keep it coming.   ;  To elaborate, lets say I have 2 threads:Thread A: world updatingThread B: renderingBasically I want the interrupting thread B to behave per the following pseudocode:start loop   turn off thread A   render the scene   turn on thread A   sleep for x msend loopI've seen a little bit in the NET framework that may be useful, but haven't yet gone to the world of NET.EDIT: Actually on review, the SetWaitableTimer function mentioned above may be what I'm looking for.[Edited by - BS-er on December 10, 2005 1:45:47 PM];Quote:Original post by BS-erTo elaborate, lets say I have 2 threads:Thread A: world updatingThread B: renderingBasically I want the interrupting thread B to behave per the following pseudocode:start loop   turn off thread A   render the scene   turn on thread A   sleep for x msend loopI've seen a little bit in the NET framework that may be useful, but haven't yet gone to the world of NET.Why do you want thread B to turn off thread A while it renders?  Surely the entire point of using threads is to allow both actions to be performed concurrently.  If you're only going to have one thread active at any one time, then why use threads in the first place?John B   ;  Have you tried spreading sleep(0) in both of your threads?To me it seems you are getting this:bbbaaaaaaaaabbbbbaaaaaaaaabbbbbbwhen you wantbaabaabaabbaababbabbaabaaabababaThe default time one thread is run in a single stretch is quite long (because thread switches lower throughput).   ;  That's a thought, or maybe the SetWaitableObject (mentioned above) in both threads.I guess the remaining criteria is that I want the render thread to effectively block the world update thread until it's done its thing (at least if that buys processing efficiency).Quote:Why do you want thread B to turn off thread A while it renders?I guess I want to avoid needless costly thread switching while the render thread runs.  The only thread switching I really need is to start the render thread so it can do a complete render cycle and then stop it.  Any more switching than that is almost a waste for my purposes.Basically I want B to interrupt A at a regular rate, but A never interrups B.  As I said, I'm trying to emulate simple (variable) timer interrupt behavior.Anyway, a little googling may shed some light.  I think I'm getting close.  Thanks for the input.[Edited by - BS-er on December 10, 2005 2:00:44 PM]