© 2004, D. J. Foreman 1 Implementing Processes and Threads

© 2004, D. J. Foreman 2 Required Software for Threads  UNIX (Linux, OpenBSD, FreeBSD, Solaris) ■ Exported POSIX API or use "Pthreads" API ■ gcc or g++ with -lpthread -lposix4 -lthread  Windows (98/ME/NT/XP/Vista/7…) ■ WIN32 API – not POSIX compliant ■ Pthreads.DLL – freeware sources.redhat.com/pthreads-win32 Copy pthread.dll to C:\windows Keep.h files wherever you want them

© 2004, D. J. Foreman 3 Exploring the Abstraction User i Processes & RAM User j Processes & RAM User k Processes & RAM CPU i CPU j CPU k User i Processes User j Processes User k Processes CPU Page space Actual RAM Abstract Loc 0 Loc n Loc 0 Loc n

© 2004, D. J. Foreman 4 Process Manager Responsibilities  Define & implement the essential characteristics of a process and thread ■ Algorithms for behavior ■ Process state data  Define the address space (and thus available content) (w/ help from memory mgr)  Manage the resources (I/O, RAM, CPU)  Tools to manipulate processes & threads  Tools for scheduling the CPU  Tools for inter-thread synchronization  Handling deadlock  Handling protection

© 2004, D. J. Foreman 5 Resources  What is a "resource" ■ Requestable blocking object or service ■ Reusable – CPU, RAM, disk space, etc ■ Non-reusable (consumable) Data within a reusable resource  R={R j |0<=j<=m} ■ R j is one type of resource, such as RAM  C={c j >=0|  R j  R(0<=j<m)} ■ c j is the # of available units of R j

© 2004, D. J. Foreman 6 Resource Mgmt Model   {Mgr} :  R j (Mgr(R j ) gives k i <=c i units of R j to P n )  P n may only request i units of Rr  P n may only request limited units of R n  Why do we need the set notation? ■ Formalized descriptions can lead to deadlock detection and prevention algorithms

© 2004, D. J. Foreman 7 Win NT/2K/XP,7,8 Process Mgmt  Split into 2 facilities: ■ NT Kernel Object mgmt Interrupt handling Thread scheduling ■ NT Executive All other Process aspects ■ FYI: See "Inside Windows 2000", 3e, Solomon & Russinovich, Ch. 6, MS Press, 2000

Fork  Parent creates a child: Main() { PID=fork(…); // spawn a child If (PID==0) child_code(); Else if (PID<0) error_code(); Else parent_code; waitpid(PID); // waits for only this child } void child_code() { } void error code() { } void parent_code() { } © 2013, D. J. Foreman 8

© 2004, D. J. Foreman 9 The Address Space  Boundaries of memory access  H/W can help (DAT) (more later)  Multiprogramming possible without H/W!!!! ■ Pre-load relocation ■ Self-relocation ■ Both use true addresses FIXED at load time ■ NO paging, but MAY have swapping Windows 3.1 IBM OS/VS1

© 2004, D. J. Foreman 10 Address Binding  Given: int function X(y,z) {int q; return ff(y,z)} Void function M {X(3,4);}  Where are X, y, z and q??  How does X get control from M?  What happens if there is an interrupt BETWEEN M's call to X and X starting?

© 2004, D. J. Foreman 11 Address Binding-2-fixed 1. Gather all files of the program 2. Arrange them in RAM in linear fashion 3. Determine runloc for the executable 4. Find all address constants (functions and External data) 5. Find all references to those constants 6. Modify the references in RAM 7. Store as an executable file 8. Run at the pre-determined location in RAM

© 2004, D. J. Foreman 12 Address Binding-3-dynamic  Perform "fixed binding", but in step 3, use a value of "zero"  In step 6, mark as "relocatable"  For step 8, before actually transferring control, REPEAT 4-6 using the actual runloc determined by the loader  Same for DLL members

© 2004, D. J. Foreman 13 Address Binding-4 DLL's  How does a program find a DLL it didn't create?  Each DLL member has a specific name  System has list of DLL member names  When DLL is requested, system fetches module and dynamically binds it to memory, but NOT to the caller!  System transfers control to DLL member

© 2004, D. J. Foreman 14 Address Binding - 5  How does the system make it look as if each abstract machine starts at 0?  How does the system keep user spaces apart  How does the system protect address spaces

© 2004, D. J. Foreman 15 Booting  Power on, BIOS/UEFI reads bootstrap program from head 0 of device  BIOS/UEFI transfers control to the OS  Bootstrap program reads the loader  Loader reads the kernel  Kernel gets control and initializes itself  Kernel loads User Interface  Kernel waits for an interrupt  Kernel starts a process, then waits again

© 2004, D. J. Foreman 16 Mode Switching - 2  Device requests interrupt  ROM inspects system for ability to accept  If interrupts are masked off, exit ■ Future interrupts may be queued by hardware ■ Or devices may be informed to re-try  If interrupts are allowed: ■ set status (in RAM, control store, etc) ■ Atomically: load new IC, privileged mode, interrupts masked off, set storage protection off  Kernel processes the interrupt

© 2004, D. J. Foreman 17 Mode Switching - 3  The actual Mode Switch: ■ Save all user state info: Registers, IC, stack pointer, security codes, etc ■ Load kernel registers Access to control data structures  Locate the interrupt handler for this device  Transfer control to handler, then: ■ Restore user state values ■ Atomically: set IC to user location in user mode, interrupts allowed again

© 2004, D. J. Foreman 18 Questions to ponder  Why must certain operations be done atomically ?  What restrictions are there during mode switching?  What happens if the interrupt handler runs too long?  Why must interrupts be masked off during interrupt handling?

© 2004, D. J. Foreman 19 What is a "Handle"?  Application requests an object ■ A window, a chunk of RAM, a file, etc.  Must give application a way to access it  Done via a "handle" ■ A counter (file handles) ■ An address in user RAM (structures) ■ Always a "typed" variable Helps insure correct usage (except "C" doesn't enforce typed usage)