XML CO527 Anonymous Questions and Answers Keyword Index

This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.

To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

Keyword reference for threads

Question 25 (2009):

Submission reference: IN1889

I've been revising thread scheduling and now seem to have two different ideas of how scheduling of processes works. I was wondering if you could tell me what of these two are correct.

The first is that there is a job-queue of process control blocks for all processes and a process (ready) queue for all processes that are ready to run. A short term scheduler runs an algorithm to choose the head of the queue, which the dispatcher dispatches.

The second is that there are kernel threads on which light-weight processes run. A user level library schedules threads to run on these light weight processes, which act as virtual processors.

Does this mean that with the latter the concept of processes no longer applies or do the former and latter work together? are there no PCBs or are they there, but only on the job-queue? Surely without PCBs the threads membership to a specific process is lost. Does this not matter? I kinda figured that the scheduling of processes and threads would take place at different levels, so the process would be scheduled then the thread would be scheduled.

Sorry that's quite a lot.

Answer 25:

In the context of this module, the first definition is correct; that is, there is a list of PCBs held in the kernel (ready queue) that the dispatcher picks for scheduling. The act of changing from one process to another is context-switching.

The second definition you have there is more related to user-level thread scheduling, which is something you'd come across in the concurrency modules (e.g. CO538, CO632). In this world, the OS kernel only knows about the threads which are 'kernel threads'. What goes on inside these (the scheduling of 'user-level threads') is something that lives in user-space entirely, and of which the OS has no explicit knowledge (nor does it care particularly). Mechanisms such as 'processes' in occam-pi or 'Fibres' in Windows are examples of these user-level threads. Such threads do not require a lot of context (e.g. machine registers, VM pages, PIDs, etc.) so are known generally as 'light-weight'. Those in the kernel (with their own PCBs) are 'heavy-weight'. In these environments, yes, thread scheduling is happening at two levels — in the kernel for the 'real' threads, and in user-space for the light-weight threads.

Keywords: threads