Introduction to Operating Systems – Windows process and thread management In this lecture we will cover Threads and processes in Windows Thread priority and scheduling Thread synchronisation Interprocess communication

Windows structure overview

Processes and threads In Windows a process consists of program code, execution context ( the address space of the process plus such things as the access token) resources allocated to the process i.e. handles, one or more threads Threads are the units of execution – they execute program code using the processes context and resources

A thread has its own context (register values including instruction pointer, execution stack, and such things as scheduling priority) Threads are scheduled onto the processor, not a process

Processes and threads are managed by 2 components in Windows: the process and thread manager and the kernel

kernel The kernel is responsible for: –Thread scheduling –Interrupt and exception handling –Low level processor synchronisation –Recovery after power failure In normal Operating Systems the kernel refers to all the operating systems components that run in kernel mode. In Windows as we have seen this applies to all the Windows Executive components (everything below the line in the diagram).

However, perversely, Windows applies the name kernel to just one component - a low level layer of the OS that manages much of the execution of threads within processes The kernel uses objects to represent and manage low level threads and processes However these kernel objects are different from those managed by the Object Manager They are lower level and provide support for the higher level objects used by the Object Manager

Process and thread manager Process manager is part of the Windows Executive and implements the representation of processes and threads that are available to other parts of the Executive and provides high level services to manage and control processes and threads Process and thread manager provides functions to –Create and destroy processes –Control resource allocation to processes –Keep track of information about processes and threads

Processes are created by other processes by making a CreateProcess system call Unlike Unix/Linux the parent and child process are independent of each other – remember fork in Unix/Linux creates the child as a copy of the parent and hence has a copy of the parents address space In Windows child process has completely separate address space, etc. Hence Windows does not keep track of process hierarchies

Thread scheduling Windows maintains a list of threads that are in the system Threads may be in one of several different states Ready – thread can execute but waiting for a processor Running – running on a processor Standby - selected to run next on a processor

Waiting – unable to execute until some event occurs (typically I/O) Terminated All processes have at least one thread known as the base thread – created when the process is created

The kernel implements the dispatcher code, which determines which thread to run next The dispatcher implements pre-emptive scheduling among threads The dispatcher schedules threads without reference to the process they belong to – hence a process that has more threads will if everything else is equal have a greater share of the processor

The scheduling algorithm is based on a multilevel priority queue approach with each thread having a priority and hence belonging to a given queue A ready thread is placed in the queue which represents its assigned priority There are 32 priority queue levels designated by numbers with 31 highest priority and 0 lowest Dispatcher starts with highest priority queue and schedules threads in order in queue in round robin fashion

Each thread is given a time quantum in which to execute and it either blocks itself waiting on some I/O event or synchronisation event or the quantum expires Once a given queue is empty, the dispatcher then proceeds to the next lowest priority queue and so on until the queues are all empty or a higher level priority thread enters a ready state i.e. one of the higher level queues is now no longer empty – and dispatcher pre-empts lower priority running thread

Highest priority levels (16-31) is for real- time threads (needing immediate responsiveness) – the real-time priorities are static Lower priority levels (0-15) are for dynamic priority threads A processes base thread is given a base priority – which is the minimum priority a thread can have

Each process has: a base priority class (a range of priority levels which the define the possible range of base priorities) and a base priority level which specifies the relative base priority a threads should have in the base priority class

Each thread then takes on priority values dynamically i.e. it changes over time e.g. if the thread is delayed waiting on an I/O event, when the I/O event occurs and the thread becomes ready again, its priority is increased temporarily. The size of the increase depends on the length of the wait – the longer the wait the greater the increase in priority

Traps and exception handling Kernel implements a trap handler which deals with hardware interrupts and processor exceptions The trap handler disables interrupts, determines the cause of the interrupt, saves processor state, re-enables interrupts and dispatches code to deal with type of interrupt/exception found (Interrupt service routine for I/O events or traps from running code to request some service or exception handler to handle problems such as attempt to execute invalid instruction)

Thread synchronisation Windows provides a set of dispatcher objects which can be used for synchronisation of thread behaviour These dispatcher objects can be in a signalled state (when the event that the thread is waiting for occurs) or a unsignaled state (when the event has not yet occurred)

Event objects represent events such as I/O events – when the relevant event occurs the object manager sets the event object to the signalled state Mutex objects provide mutual exclusion – only one thread can have a mutex object – it does this by setting the object into an unsignaled state. Once the thread completes its activity it sets the mutex object to the signalled state Waitable timer objects – these objects remain unsignaled until a given time has elapsed

Interprocess communication Threads (and hence also processes) can communicate using a variety of methods Pipes – work very similar to Unix – unidirectional communication via a shared buffer Sockets – similar to pipes but usually connect processes and threads on different machines Remote procedure calls – allows a thread in one process to invoke the execution of code in different processes address space File sharing is also implemented