Implementing Processes and Threads

1. Implementing Processes and Threads

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

3. Exploring the Abstraction Loc 0Loc n Loc 0Loc n Loc 0Loc n User i Processes & RAM User j Processes & RAM User k Processes & RAM CPU i CPU j CPU k Abstract Actual User i Processes User j Processes User k Processes RAM Loc 0 Loc n CPU Page space

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) • 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

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={Rj|0<=j<=m} • Rj is one type of resource, such as RAM • C={cj>=0| RjR(0<=j<m)} • cj is the # of available units of Rj

6. Resource Mgmt Model •  {Mgr} : Rj (Mgr(Rj) gives ki<=ci units of Rj to Pn) • Pn may only request i units of Rr • Pn may only request limited units of Rn • Why do we need the set notation? • Formalized descriptions can lead to deadlock detection and prevention algorithms

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

8. Fork • Parent creates a child: Main() { PID=fork(…); // spawn a child If (PID==0) child_code(); Else if (PID==NULL) error_code(); Else parent_code; waitpid(PID); // waits for only this child } void child_code() { } void error code() { } void parent_code() { }

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

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?

11. Address Binding-2-fixed • Gather all files of the program • Arrange them in RAM in linear fashion • Determine runloc for the executable • Find all address constants (functions and External data) • Find all references to those constants • Modify the references in RAM • Store as an executable file • Run at the pre-determined location in RAM

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

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

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

15. Context Switching • Power on, ROM reads bootstrap program from head 0 of device • ROM transfers control to the program • 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

16. Context 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

17. Context Switching - 3 • The actual Context 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

18. Questions to ponder • Why must certain operations be done atomically? • What restrictions are there during context switching? • What happens if the interrupt handler runs too long? • Why must interrupts be masked off during interrupt handling?

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)