Thread Quantum: How to Compute It

Thread Quantum: How to compute it

1. On Linux, the default realtime quantum length constant is declared as RR_TIMESLICE, at least in 4.x kernels; HZ must be defined while configuring the kernel.
2. The interval between pausing the thread whose quantum has expired and resuming it may depend on a lot of things like, say, load average.
3. To be able to predict the running time at least with some degree of accuracy, give the target process realtime priority; realtime processes are scheduled following a round-robin algorithm, which is generally simpler and more predictable than the common Linux scheduling algo.
4. To get the realtime quantum length, call sched_rr_get_interval().

Thread Quantum?

Thread Quantum is the amount of time that the schedule allows a thread to run before scheduling a different thread to run.

What are threads?

Platform Builder: Setting the Default Thread Quantum

As far as editing goes...There is a registry setting in windows that allows priority changing:

HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Control /
PriorityControl / Win32PrioritySeparation

0 Foreground and background applications equally responsive

1 Foreground application more reponsive than background

2 Best foreground application response time

Increase thread quantum from user-mode

I doubt it's possible. I quickly found this page ( http://www.javamex.com/tutorials/threads/thread_scheduling_2.shtml ) which suggests that a thread's quanta length is variable anyway, and subject to many attributes of the execution environment.

I suppose if you really needed to it should be possible to write a kernel module that alters it, but then you're entering painful territory.

What are you doing that needs longer quanta lengths anyway? Maybe there's an alternative approach.

Scheduling and thread quantum

Unless your operating system was designed from the ground up to be a hard-real-time OS (e.g. Xenomai or VxWorks), you'll find that the OS's scheduler provides very, very few guarantees about when your threads will get to run, or how long they will get to continue running for when they do run.

Given the above, it's entirely likely that the presence of other threads on the same computer (whether they are threads inside your own process or threads in other processes) will affect the amount of CPU time that your own threads receive. For example, if the other threads are running at a higher priority than your threads, and there is contention for CPU cores (i.e. more threads want to run at a particular time than there are CPU cores to run them on), then the scheduler will kick one of your running threads off its current CPU core before its quantum expires, so that the now-ready-to-run higher-priority thread can begin executing immediately.

In general, the answer to this sort of question is of the "there be dragons" variety -- which is to say, if you have written your multithreaded program correctly, then you shouldn't have to know (or care) what quantum-sizes your threads receive, as your code should be able to run correctly regardless of exactly how the scheduler hands out time slices to threads.

(The exception is when you absolutely need real-time behavior; in that case you probably want to be running on a real-time OS that can provide you with the guarantees you need)

As for how much time it takes the scheduler to determine which thread to start running, having more threads does increase the scheduler's overhead, but on most operating systems the increase is very marginal -- the scheduling algorithm is O(log N) or even O(1) with respect to number-of-threads. You can still make the computer "hit the wall" if you keep adding more threads indefinitely, of course, but the limit you finally hit will more likely be related to RAM exhaustion than the performance of the scheduling algorithm.

---

Related Topics