I'd rather this be a comment but it takes too many characters. Anyways, ozgur, judging by the questions in your comment responses you seem to be missing the point that you can't simply say my thread takes this long to run and expect it to magically work in conjunction with other threads all thanks to the OS. You have to design your threads and analyze them for the worst case performance. If the worst-case doesn't meet your requirements then you need to redesign your threads.
So rather than simply say thread 1 takes 10 ms to complete and thread 2 takes 20 ms, you have to also say thread 1 must execute every 15 ms. thread 2 must execute every 40 ms. thread 3 must execute every 500 ms, threadN must execute every 1500 ms. Then you allocate time for how long each thread can take to complete in the worst case scenario. You put all that together, identify the worst possible scenarios and then you have to make sure every thread meets its timing requirements. This analysis is also where you identify if some threads need to be higher priority than others in order to meet their timing requirements.
For example, thread5 is running gets interrupted by thread 4 which gets interrupted by thread 3 which gets interrupted by threadN might be one worst case scenario. You put all this on a timeline and verify that even in this worst case scenario every thread meets its timing requirements. You can ensure the threads complete this worst case scenario deterministically by using the scheduler and priorities in a real-time OS. That determinism is what makes for a real-time OS.
If you make threads the same priority then you have lost some (if not all) of that determinism because the scheduler may be free to choose whichever thread it wants to run next.
In an OS like Windows, not only can you not specify when each thread will run, you can't even guarantee that your application is going to be running at any point in time. The OS could halt your application and run some background service whenever it chooses. In other words, there is no determinism. Thus, Windows is not a real-time OS. Although, if your timing requirements are large, like (thread1 runs every 10 seconds, thread2 runs every 15 seconds) then you can essentially treat Windows like a real-time OS as long as you account for the slop and approximately every 10 or 15 seconds (give or take a few hundred milliseconds and an occasional missed window) is good enough.