sharing, interactive, realtime, etc.), which we will touch on later. Suffice it to say that with a SCS
thread, you can set the kernel-level scheduling class and priority using the process-level API.
The primary conclusion in both cases is that you should see no particular differences between
locally and globally scheduled threads as long as there are sufficient LWPs.
Context Switching
Context switching is a rather complicated concept and has many details of significance, so it is
difficult to explain in just a few paragraphs. Nonetheless, we shall try. If you don't feel that you
have a firm grasp of how it works, you should go bug a friend to explain all of the subtle nuances.
Threads or no threads, you should understand this concept thoroughly.
A context switch is the act of taking an active thread off its LWP and replacing it with another one
that is waiting to run. This concept extends to LWPs and traditional processes on CPUs also. We
will describe context switching in traditional, process/CPU terms.
The state of a computation is embodied in the computer's registers--the program counter, stack
pointer, and general registers--along with the MMU's (memory management unit) page tables.
These, plus the memory contents, disk files, and other peripherals, tell you everything about the
computer. When it's time to context switch two traditional processes, the register state must be
changed to reflect the new process that we wish to run. It works approximately like this:
·
All the current registers are stored into the process structure for P1.
·
All the stored register values from the process structure for P2 are loaded into the CPU's
registers.
·
The CPU returns to user mode, and voila! P1 is context switched out and P2 is context
switched in and running.
All the other data in the process structure (working directory, open files, etc.) remain in the
process structure where it belongs. If a process wishes to use that data, it will reference it from the
process structure. When two LWPs in the same process context switch, all of the above happens in
much the same fashion.
Notice also that a context switch must be done by the CPU itself. One CPU cannot do the context
switch for another. CPU1 can send an interrupt to CPU2 to let it know that it should context
switch, but CPU1 cannot actually change the registers in CPU2. CPU2 has to want to context
switch.
Finally, context switching for PCS threads involves much the same procedure. A thread (T1)
decides that it has to context switch (perhaps it is going to sleep on a synchronization variable). It
enters the scheduler. The CPU stores its register state into the thread structure for T1, then it loads
the registers from another thread (T2) into the CPU and returns from the scheduler as T2. No
system calls need be involved. It is possible that it happens completely in user space and is very
fast.
It may be a bit unclear what the role of the LWP is when threads context switch. The role is
invisible. The threads save and restore CPU registers with no regard to the LWP at all. The threads
scheduler does not do anything to the LWP structure. Should the operating system decide to
context switch the LWP, it will do so completely independently of what the LWP happens to be
doing at that time. Should two threads be in the middle of context switching when the kernel
decides to context switch the LWP, it still makes no difference. The threads' context switch will
just take a little longer.
Search WWH :
