Jump to content

  • Log In with Google      Sign In   
  • Create Account

This may sound stupid ... [multitasking]


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 Noctumus   Members   -  Reputation: 269

Like
0Likes
Like

Posted 19 February 2014 - 02:57 PM

In this article on MSDN about mutitasking the author mentions that each thread on a Windows system runs for the duration of a "time slice" and that one of these time slices is around 20 milliseconds. In another article I read the author referes to time slices as "quantums" and wrote that they are usually around 15 milliseconds on a Windows system.
 
Now, what I don't understand is that when I run a program and use a timer (like QPC/QPF or timeGetTime) to continuously spit out time-stamps it seems my program is indeed not suspended every 15-20 milliseconds. In fact, it looks like it isn't suspended at all.
 
Also, when I ran the program there was a total of 618 threads running on my system which means that if each of them was granted a 20 milliseconds time slice each thread would have to wait no less than 12.36 seconds every time it had worked for 20 milliseconds, which obviously isn't the case. I know a lot of these threads are sleeping most of the time, but even when I had Left 4 Dead 2 running which has 45 threads (during gameplay) and uses quite a lot of CPU resources it still didn't seem to affect my program ... ?


Sponsor:

#2 rip-off   Moderators   -  Reputation: 8763

Like
2Likes
Like

Posted 19 February 2014 - 03:38 PM

In fact, it looks like it isn't suspended at all.

That is the idea!

Threads can run for up to a time slice / quantum before the OS decides what to run next. You might have 618 threads, but not all are equal. There is priority, high priority threads will run more often than low priority threads. Some threads might be blocked, waiting on I/O or other signal - these will not be considered for scheduling until the I/O completes or signal is triggered. Even if one of the 618 threads is runnable, but only has less than a millisecond of work to do, it will release the time slice / quantum early (typically by blocking, but potentially just by yielding the processor), and the OS will pick another thread immediately.

Try starting a number of instances of your program, they'll eventually fight one another for processor time.

Edited by rip-off, 19 February 2014 - 03:40 PM.


#3 Noctumus   Members   -  Reputation: 269

Like
0Likes
Like

Posted 19 February 2014 - 04:30 PM

Threads can run for up to a time slice / quantum before the OS decides what to run next ...

Thanks for your explanation. I think the "up to" part explains a lot and that 20 milliseconds uninterrupted CPU time for a thread is definitely more the exception than the rule wink.png






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS