Thread Quantum

[Lateral:Brain-Q]

Hi,

A Thread Quantum, is the amount of time a Thread gets to run, before another Thread with same priority or a Thread with Higher Priority in the Ready State is waiting to run.

The default Thread Quantum on Windows 2KP/XP is 2 Clock Ticks and on Windows Server Systems, the default value, is 12 Clock Ticks.

But internally default Thread Quantum values are stored as multiple of Three times the number of Clock Ticks.

1] Why is the Internal Default Thread Quantum values stored as multiple of Three Times?

2] Why not, a multiple of a number <3 or >3 ?

3] How to determine the Length of the Clock Ticks?

Thanks

[Net2Infinity]

I did some googling and here is the best reference for you.


http://www.microsoft.com/mspress/boo...chap/4354c.asp

[Lateral:Brain-Q]

Thanks Net2Infinity for the link.

The reason quantum is expressed in terms of a multiple of 3 quantum units per clock tick rather than as single units is to allow for partial quantum decay on wait completion. When a thread that has a base priority less than 14 executes a wait function (such as WaitForSingleObject or WaitForMultipleObjects), its quantum is reduced by 1 quantum unit. (Threads running at priority 14 or higher have their quantums reset after a wait.)

This partial decay addresses the case in which a thread enters a wait state before the clock interval timer fires. If this adjustment were not made, it would be possible for threads never to have their quantums reduced. For example, if a thread ran , entered a wait state, ran again, and entered another wait state but was never the currently running thread when the clock interval timer fired, it would never have its quantum charged for the time it was running.


Above was the explanation from the link why Quantum is stored as multiple of 3 Clock Ticks. I'm completely lost with the explanation of Partial Quantum Decay on Wait Completion.

Why is it, when a Thread with base priority < 14 executes a Wait function, the Quantum is reduced by 1 and whereas for a Thread with base priority >= 14 has the Quantum reset after the Wait?

I don't understand the reasoning in 'For example, if a thread ran . . . . . . . . . ' because, if a Thread is currently running, why wouldn't the Quantum be reduced irrespective of the fact whether the Quantum is 2 Clock Ticks or a multiple of 3 Clock Ticks before it enters the Wait state?

Thanks

[nihil]

I have an even more interesting question:

Just what the hell has this to do with Newbie Security Questions ?

Thread moved.....................

[sec_ware]

Hi

These are good questions. As usual, I wanted to keep my answer short,
but the post ended up almost as a tutorial.

...nihil, these questions could be somewhat related to availability
questions, hence security. Whether this belongs to "newbie questions"
or not, may be questionable


I paraphrase the issue in order to prepare my answers (party you already have
answered your questions, but I will answer them again ):


thread quantum and thread states

A thread gets a certain amount of time to run, called a thread quantum.
For simplicity, this time spans 2 clock ticks, or (20 resp 30ms -> see below "determine clock ticks")
to fix the idea.

This thread quantum is measured in units three times the clock tick, ie.
6 units = 1 thread quantum = 2 clock ticks = 20 (or 30) ms.


It is of prime importance to understand the states, a thread can be assigned to:
1. running: the thread is running.
2. ready: the thread is on queue to be executed
3. standby: the thread is the next one to be executed
4. waiting: the thread is in a wait state (waiting for pending objects, ...)
5. terminated: the thread has exited

There are more, but these are the relevant ones. One must understand that
threads, which are waiting, are not running. While they are waiting (e.g. for
I/O processes to be completed), other threads can run.


running vs waiting and the priority-dependency


Simplified picture:

a) If a thread is running, then its thread quantum is reduced by 3 when the clock fires a tick.
b) If the thread is waiting, then its thread quantum is reduced by 1 when the clock fires a tick.


This has to be done because some threads may be in waiting state almost always. Hence, the
probability to have their thread quantum reduced without b) is negligible.


Incorporating priorities to the picture:

31 = Realtime - level: time critical
16 = Realtime - level: idle
15 = Dynamic - level: time critical
1 = Dynamic - level: idle
0 = System

1-6: range of idle thread. base-value = 4
4-8: range of "below normal" thread. base-value = 6*
6-10: range of "normal" thread. base-value = 8*
8-12: range of "above normal" thread. base-value = 10*
11-15: range of "high" thread. base-value = 13
16-31: range of realtime threads. base-value = 24

*processes have only two "normal"-levels, base-value 7 and 9.


If the current priority of the thread is 15 or less, and its base priority is 13 or less, then this
process b) is applied. Otherwise, the thread quantum is reset.
What are these priorities describing?
First remark: the highest possible priority of a dynamic-level process/thread is 15, even if the priority
boost would result in a higher priority.
Second remark: processes with a base-value 14 and 15 are particular system processes,
which are able to execute NtSetInformationProcess (usually 14).

Hence, b) is applied to all "ordinary" threads running in the dynamic-levels.




How to determine the time span of one clock tick

The kernel32.dll-function GetSystemTimeAdjustment[1] has the answer for you:

lpTimeIncrement
[out] A pointer to a variable that the function sets to the interval between periodic time adjustments, in 100-nanosecond units. This interval is the time

period between a system's clock interrupts.

I have written a simple c-program to illustrate its usage:

#include <windows.h>
#include <stdio.h>

int main(){

  unsigned long lpTimeAdjustment;
  unsigned long lpTimeIncrement;
  int lpTimeAdjustmentDisabled;
  int ret;
		
  ret=GetSystemTimeAdjustment(&lpTimeAdjustment,&lpTimeIncrement,&lpTimeAdjustmentDisabled);
  if (ret>0){
  
	printf("time-of-day addition (ms): %f\n",(float)lpTimeAdjustment / 10000);
	printf("\"clock tick\" time span (ms): %f\n",(float)lpTimeIncrement / 10000);
	printf("time adjustment in effect (TRUE 1/FALSE 0): %d\n",(float)lpTimeIncrement / 10000);
  }

	return 0;
}

To anwer your questions directly:

1] Why is the Internal Default Thread Quantum values stored as multiple of Three Times?

To allow for partial quantum decays.

2] Why not, a multiple of a number <3 or >3 ?

for optimisation reasons. certainly, one could measure in units of twice the clock ticks,
or four-or five time the clock ticks, but there is no gain. There may be other logical reasons
as well, but I am not aware of them.

3] How to determine the Length of the Clock Ticks?

see above.



If you want to play around, I recommend sysinternal's process explorer[2]. If you want to go
deeper, use a kernel debugger (kd[3] via windbg with symbols[4], softice).

Cheers


P.s. Two books I can recommend:
1. "Windows internals" by M.Russinovich - general overview
2. "Windows System Programming" by Johnson M. Hart - more practical aspects


[1] http://msdn.microsoft.com/library/de...adjustment.asp
[2] http://www.sysinternals.com/Utilitie...sExplorer.html
[3] http://www.microsoft.com/whdc/devtoo...nstallx86.mspx
[4] http://www.microsoft.com/whdc/devtoo...symbolpkg.mspx

[Lateral:Brain-Q]

sec_ware, Thankyou for your explanation. It was great.

A Thread in the 'Running' State will have its Quantum decremented by 3 Units per Clock Interrupt.

A Thread in the 'Wait' State will have its Quantum decremented by 1 Unit per Clock Interrupt. So a Thread in the 'Wait' State will have a total of 6 Quantum Units and it is decremented by 1 Quantum Unit per Clock Interrupt. The reason to deduct 1 Quantum Unit per Clock Interrupt is that the Thread in the 'Wait' State has a potential to switch to a 'Running' State and can utilize any available Quantum to run. If it does not switch to 'Running' State, but remains in the 'Wait' State, its Quantum is decremented by 1 Unit and eventually its Quantum ends.

sec_ware, was the above interpretation correct?

From what I've been reading, a Process has a Base Priority Class [Real-Time, High, Above Normal, Normal, Below Normal, and Idle]. Threads, inherit the Process Base Priority. Threads also have Current Priority.

In your reply, under 'Incorporating Priorities To The Picture' heading:

I, understood the different Thread Priority Levels. But, How did you derive the different ranges for Threads and how were you able to calculate the Base-Values?

Also, if I might, lets say a Process has a Base Priority Class of for example, Above Normal. What Numeric Value does it translate to? Will it be the value for Thread's Base Priority? What would be the Thread's Current Priority?

BTW, I'm planning to buy the book on Windows Internals. Now, I'm not much of a Programmer. Will you still recommend me to buy the Windows System Programming book? I'm thinking of learning C. Will I be able to code "C" on a Microsoft OS and be able to use Windows Functions?

ThankYou.

[sec_ware]

Hi

I would say that your interpretation is correct. I'd like to comment on one
small point: when a thread is exiting the wait state, it actually becomes
"ready" in principle - in a few cases, e.g. its priority is high enough,
which is possible due to "priority boosts", the thread runs immediately.
However, the overall situtaion is even more complicated


A more refined view on the priorities (base level) is available at microsoft[1].
The combination of the process priority class (6 types) and the thread priority
(7 types) will result in the thread base priority number (0/1-31).


The thread current priority is initially equal the base priority. However,
there are various situations, where a priority boost or reduction is necessary.
Thus, the thread current priority is subject to changes, but usually does not
exceed 15.



If you are not a programmer, do not buy windows system programming. Stick to
windows internals. But your question shows something important:
learning a programming language is a simple thing - it is much harder to
get an overview about all the classes, functions, ... which are available,
either in the microsoft world or another. To make the point more clear:
System programming is "trivial" from a "source-code-point-of-view" - but
extremely difficult to understand all the concepts and specifications, like
the ones in [1]. This is a result of operations research, refined again and
again by trial-and-error...and still should be refined


Cheers


[1] http://msdn.microsoft.com/library/de...priorities.asp

[Lateral:Brain-Q]

sec_ware, Thankyou again for your explanation. I've bookmarked your link. I've also downloaded the debugging tools for Windows. I'll try what I can learn from WinDbg.

Thanks

[Lateral:Brain-Q]

Hi,

I wanted to learn more about Thread's Switching States. What I did was open Performance Monitor and chose 'Thread' as the Performance Object and selected 'Thread State' counter and 'Instances' for Internet Explorer. There is only one window open for Internet Explorer.

I changed the Vertical Scale Numbers from 0 to 7 as these are the values for a Thread State.

In the Task Manager, I see 29 Threads for IEXPLORE.exe

In PerfMon, there are 18 Instances for IEXPLORE. All I see in PerfMon is that every single Instance of Thread State Counter is at value 5 which implies it is in a Wait State.

What action[s] can I take to see a Thread Switching its State from a Wait to Running? Or is this something that can only be accomplished Programmatically?

Thanks

/Edit: After writing the above, I closed Internet Explorer and checked PerfMon to see if the Thread's State Switches from Wait to Terminated. Did not happen. Don't know why.

[sec_ware]

Hi

If you have an appropriate program, you can see the
thread status switching. It should be a program, that
does some intensive calculation for a while (perfmon
takes snapshots), and waits for some user interaction.

I did write a little extremely ugly program (in vb.net),
which exactly does this. Using perfmon (add thread.thread state
and choose the threads of this executable)

 
       Dim j, l As Integer
        Dim a As Integer

        While (True)
            For l = 1 To 1000000
                For j = 1 To 10
                    Try
                        a = Pow(l Mod 5, j)
                    Catch ex As Exception
                        MsgBox(ex.Message)
                    End Try

                Next

            Next
            MsgBox("Hello World!")
        End While

Cheers