1

Sorry for my weak english, by preemption I mean forced context (process) switch applied to my process.

My question is :

If I write and run my own program game in such way that it does 20 millisecond period work, then 5 millisecond sleep, and then windows pump (peek message/dispatch message) in loop again and again - is it ever preempted by force in windows or no, this preemption does not occur?

I suppose that this preemption would occur if I would not voluntary give control back to system by sleep or peek/dispatch in by a larger amount of time. Here, will it occur or not?

Ferdinand.kraft
  • 12,579
  • 10
  • 47
  • 69
grunge fightr
  • 1,360
  • 2
  • 19
  • 38
  • You live and die by the OS scheduler (and that is not exclusive to Windows). Write your program like it can be preempted at any time (because it probably will be). – WhozCraig Aug 19 '13 at 17:00

2 Answers2

2

The short answer is: Yes, it can be, and it will be preempted.

Not only driver events (interrupts) can preempt your thread at any time, such thing may also happen due to temporary priority boost, for example when a waitable object is signalled on which a thread is blocked, or for example due to another window becoming the topmost window. Or, another process might simply adjust its priority class.

There is no way (short of giving your process realtime priority, and this is a very bad idea -- forget about it immediately) to guarantee that no "normal" thread will preempt you, and even then hardware interrupts will preempt you, and certain threads such as the one handling disk I/O and the mouse will compete with you over time quantums. So, even if you run with realtime priority (which is not truly "realtime"), you still have no guarantee, but you seriously interfere with important system services.

On top of that, Sleeping for 5 milliseconds is unprecise at best, and unreliable otherwise.

Sleeping will make your thread ready (ready does not mean "it will run", it merely means that it may run -- if and only if a time slice becomes available and no other ready thread is first in line) on the next scheduler tick. This effectively means that the amount of time you sleep is rounded to the granularity of the system timer resolution (see timeBeginPeriod function), plus some unknown time.
By default, the timer resolution is 15.6ms, so your 5ms will be 7.8 seconds on the average (assuming the best, uncontended case), but possibly a lot more. If you adjust the system timer resolution to 1ms (which is often the lowest possible, though some systems allow 0.5ms), it's somewhat better, but still not precise or reliable. Plus, making the scheduler run more often burns a considerable amount of CPU cycles in interrupts, and power. Therefore, it is not something that is generally advisable.

To make things even worse, you cannot even rely on Sleep's rounding mode, since Windows 2000/XP round differently from Windows Vista/7/8.

Damon
  • 67,688
  • 20
  • 135
  • 185
  • Do mouse preempties (tears) my calculation frames, or this do occur more in the sleep or message puump time periods? do scheduler organizes that - this is main information Im searching for – grunge fightr Aug 20 '13 at 08:37
  • 1
    The scheduler cannot "organize" that, since it has no control over when an external event (e.g. mouse moved or network card received something) happens, and these usually need to be handled immediately. Granting a non-preempted quantum based on "credit" would be detrimental to overall responsiveness. – Damon Aug 20 '13 at 10:08
  • this makes some sense - but we are talking here about hardware interrupts maybe not prosess switching.. process swithing is more related to switching one heavy working program to another heavy working and scheduler would be doing wiser if make switch when the first is sleeping I think - Do schedulet totally ignores when the first one is working when sleeping and just forces everything ? – grunge fightr Aug 20 '13 at 16:10
  • As stated above, your thread does not earn "bonus points" for sleeping. The OS scheduler gives away time slices as they become available, depending on priorities. The Windows scheduler in particular serves all higher prio tasks first, interrupting lower priomtasks if necessary. Priority is further dynamic (see "boost"). So yes, this also happens without haedware interrupts. – Damon Aug 20 '13 at 17:35
1

It can be interrupted by a driver at any time. The driver may signal another thread and then ask the OS to schedule/dispatch. The newly-ready thread may well run instead of yours.

These desktop OS, like Windows, do not provide any real-time guarantees - they were not designed to provide it.

Martin James
  • 24,453
  • 3
  • 36
  • 60
  • Ok but it is not only about guerantees, What about investigating this at runtime - can I collect some information about this preempting events in the runtime - If they are present how long they take ?? I am using some pair of timer-askings at the begining and at the ent of every frame (this 20 milisecond loop cycle) and i never notice any picks - It is I notice them when I am starting itunes to play mp3 music; But here no guarantees but it seem probably such forced/frame tearing preemption does not occur in reality - there are some rules i do not know, searching to know them – grunge fightr Aug 19 '13 at 17:46
  • The 'forced preemption' HAS to happen to provide good I/O performance. It's the main reason for having the complication of a premptive multitasker in the first place. – Martin James Aug 19 '13 at 17:57