   Multithread slowdown
  Well, I fear I might have gotten a wrong concept on how Windows treats multiple threads priority. It's not my first multithreaded project, but it is the first time I get this bevahiour (maybe W2k?)Anyway, using single thread:   //*********************for (;;; ){   PoolMouse();   DrawGLScene();}//********************  I get ~arround 120 to 140 fps on averageNow same thing in a multithread setup...   //***************************_beginthread(PoolMouseLoop,0,NULL); //or CreateThread, whicheverfor (;;; )  DrawGLScene();//***************************void PoolMouseLoop(void){for (;;; )   PoolMouse();}  Obviously, since a mouse poll will take less to complete than drawing a GL scene, I figure this will give me several pollings per frame.. hence I do expect a small reduction in fpses... However, on a multithread configuration i get 30-40 fps...almost a 1/4th of the singlethreaded one.Ideally I'd like to separate the two (graphics and inputs) into 2 separate threads.The way it is now, the penalty for this is just prohibitive... Any ideeas how this is normally done, so I don't decimate the fps, yet have separate threads for the two?[edited by - Radu094 on February 19, 2004 4:11:35 AM]
  In your poolmouse function, do you call any opengl functions ?If it is, you have collision in your multithread program. Don't forget OpenGL is a state machine where some instructions cannot be used in certain states (see instructions allowed between glBegin() and glEnd() states for example). To avoid those collisions you need to create a mutex called by each of these functions (see waitforsingleobject).Hope that helps.Ghostly yours,Red.EDIT: reread your post and decided to add a little more precisions.  You may have also collisions if the PoolMouse function updates mouse screen coordinates used by the DrawGLScene function. This is also why you need a mutex. On windows like any other OS, time is cut into little steps (it is called discrete): the OS fire a thread at each of these little steps. You do not know when a thread is fired and which thread is fired. This is why there are objects that help you synchronize   your threads.The objects are the Mutex, Event, Semaphore, Timer and Critical sections (the win32 programmer reference   is very clear about why and how to use them).When realizing multithreaded programs, you need to pay attention to details since bugs are difficult to find when you have a collision. In your multithreading test, you created a thread which you never knew when it was fired causing a loss of FPS. Be aware that non synchronized threads sharing resources can have much worse consequences (including crashing the OS).Ghostly yours,Red.   [edited by - Red Ghost on February 19, 2004 5:13:36 AM];  Hi ! No, I''m trying to keep all drawing to one thread and one pooling to other.More like: //***************************_beginthread(PoolMouseLoop,0,NULL); //or CreateThread, whicheverfor (;;; ){ DrawGLScene();  Mouse->DrawMouse();}//***************************void PoolMouseLoop(void){for (;;; )   Mouse->PoolMouse();}What I begin to fear is that Windows is assigning them equal processor time, not equal ''instruction numbers'' . I''m sorry, I''m not familiar with the actual term , but could this be possible? Something to do with procesor cycles vs. actual instructions? I mean, even if I use While (True); in my second thread, the FPS in the first thread drops by >half.;  I edited my post. please see above.Looks like mouse coordinates variable collision. There are two possibilities: a critical section or a mutex.Ghostly yours,Red. ;  if you do a while(true); in one thread, then windows (or any operating system) will assign half the cpu time to that thread... but context switch time will ensure that you have a greater than half slowdown. ;  @AP: I disagree. By default, the OS will share approximately equal time between all threads within a process. Under windows this time shared depends on the number of processes and the priority settings for the current process (see the system settings).Be aware that time share is independant of code content. Thus while (true)has no influence whatsoever on the time slice.The time share for each thread within a process can be tuned by setting its priority class (but you need to use it with care see win32 reference on scheduling priorities).You also have the means to control the flow of threads within a process:- the thread is manually halted by SuspendThread or SwitchToThread (win32 functions).- the thread is automatically halted by a synchronization object (see the list of synchronization objects in my previous post).To quote the win32 programmer reference: quote: When a running thread needs to wait, it relinquishes the remainder of its time slice.Ghostly yours,Red.EDIT: there are two tutorials by Dan Royer on multithreading at flipcode.look at Multithreading   and Multithreading: part II  Ghostly yours,Red.   [edited by - Red Ghost on February 19, 2004 6:10:56 AM];  I added a mutex on accesing the mouse coordinates for reading/writing. It solved the jaggeness on the mouse (who kept jumping on the screen), thanks!    I still get a huge slowdown though , and if this is true (that 2 threads will get 1:1 time) then I kinda fail to see why people even use multithreading to separate the input from graphics.???My app is not that input-time critical anyway, so if there isn''t any other benefit (other than halfing the FPS, I mean) I''m thinking about merging them back together...;quote:Original post by Red Ghost   When a running thread needs to wait, it relinquishes the remainder of its time slice. Oh, I posted w/out refreshing and missed your post. I''ll take some look at thread priorities and see if I can sort some combination that works...;  To remove the slowdown, you have three solutions:- change the thread priorities (be aware that by default a thread priority is set to normal; remember that your main program is also a thread).- use a timer object to control your polling by increasing the time between polls.- use the function sleep(0) at the end of your polling function to automatically relinquish your polling thread time slice.The use of multithreading is indeed an advantage on certain calculus intensive programs:- database management- 3D engines for large terrain when separating the mesh calculations from the mesh rendering functionsYou can look an example at source islands (see into x86 then 3D engines).Still a multithread process will be always a little slower than a single thread process because of the time slice management. This slight slowdown can only be offset when you have some part of your program which is really calculus intensive and which robs the user of the interactivity he needs.This is why in some games the input is separated from the graphics engine to give back the user the interactivity he is missing.Hope that helps.Ghostly yours,Red. ;  I think you''re losing a lot of time in the context switch from one thread to the other (big overhead!). I think the best thing to do is to redesign your mouse thread as:void MousePoll (void){    while (true)    {   WaitForMouseEvent ();   ProcessMouseEvent ();    }}  where the WaitForMouseEvent is an event handler for the mouse input - I think DirectInput can give you one of these. The improvement here is that the code is only exectuded when there''s something to do (i.e. update the mouse position), rather than the busy-wait loop you''ve got. So, in effect, the handler takes 0% of CPU time for the majority of the time (events don''t occurr that often) and the render gets the rest of the CPU time.Think of the event mechanism as an interrupt handler.You may also want to up the priority of the mouse handler thread (to real time, perhaps) so it gets a good chance of completing before the OS transfers control to another thread (but you''d need to limit the time ProcessMouseEvent takes).Skizz 