CODEWITHSUNDEEP
multithreading
0xPwn
0xPwn

Reputation: 385

kernel mode scheduling - How It Works

In the world of UserMode we have processes and threads.

We have a kernel scheduler that schedules the thread running times and that's how we get "multi threads".

Now I have a few questions:

  1. In a situation where we have multiple processors, so we actually have the physical ability to really run a number of threads , how do the different processors know how to return to the scheduler? and how is "race condition" prevented?
  2. Does the "process" concept exist in the kernel?
  3. Does each driver have its own thread? (I mean, do we have a scheduler on drivers too, and everything works just like in UserMod in terms of scheduling?)
  4. Does the kernel have its own thread? (Do we also have a scheduler on the kernel itself?)

Upvotes: 2

Views: 985

Answers (1)

bazza
bazza

Reputation: 8394

  1. OSes will have a timer interrupt setup, usually at about 60ms. The interrupt handler in the OS will kick-off the scheduling algorithms, to see what's best run next. This is called preempting, because the OS does this without cooperation from the applications its running. Other interrupts - from devices - will also kick off a scheduling reevaluation. So when a new Ethernet frame is received, that may eventually result in your web browser being rescheduled resulting in a page being drawn. In the old days of Windows 3 and the like (and other early OSes of that sort), they depended on applications making calls to operating system functions to give the OS a chance to run the scheduling algorithms. This is called cooperative multi-tasking - the OS depends on the applications making those OS function calls.

  2. Depends. A microkernel based OS will actually put a lot of what we think is OS code into processes (e.g. device drivers), and run them at no higher privilege than other userland applications. Windows and Linux aren't like this.

  3. Again, depends. In Linux the drivers were simply functions that'd get run whenever, or if the Linux PreemptRT patch set was applied the bulk of this functionality was put into kernel threads, to be scheduled along with all other threads in the system. Kind of a poor man's way of getting a fully preemptable operating system. In OSes like VXWorks, the device drivers have always been threads with no more or less privilege than application threads (in fact VxWorks makes no distinction between them). This means that the whole of VxWorks is preemptable - even all the device drivers, etc - making it a very good hard real time OS.

  4. The kernel is not a thread as such, as it's the thing that defines what a thread is. But it is code executing within the system.

Upvotes: 1

Related Questions