Joonwon Lee Process and Address Space

2 Processes and Threads 2.1 Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling

3 The Process Model (a) hardware view: memory and PC (b) logical view: PC for each process (c) time line

4 Process Creation System initialization –From the init process, … process creation syscall : fork() User request to create a new process –ls, cd, …. Initiation of a batch job

5 Process Termination Conditions which terminate processes 1.Normal exit (voluntary) 2.Error exit (voluntary) 3.Fatal error (involuntary) 4.Killed by another process (involuntary) Reasons for the zombie state in Unix –Parent process may want to know child process’s status

6 Implementation of Processes (1) Some fields of a process table entry(PTE, PCB)

7 Implementation of Processes (2) Skeleton of what OS does when an interrupt occurs

8 Address Space A range of space where a process can access Limited by OS and hardware Protection domain Usually a unique space is given to each process Sharing and Protection in a Single Address Space

Overview Backgrounds –advent of 64 bit CPU: Alpha, HP PA-RISC, MIPS R4K –sharing between applications are intrinsic CAD, CASE The Big Ideas –single address space everyone in one space you can access anything –64 bit is big enough? it takes 500 yrs if you consume one GB per second

10 Private Virtual Address Space Each process is given the same amount of address space address space of process A address space of process A address space of process A address space of process A address space of process A process B process C process D

11 Private Virtual Address Space(2) virtual addresses are translated into real addresses –page table per each process is necessary –at each context switching, page table at work is changed, too Difficult to share –sharing needs kernel intervention Good protection –you cannot access other process’s area without kernel permission

12 Cooperation between applications

13 Why Single Address Space? Easy sharing –pointer-based data structure can be used for sharing –application can control the sharing –better integration of large applications Virtual cache memory –no synonym problem –cache lookup is possible before address translation

14 Opal Segment, Threads, Protection Domain –access to a segment is controlled by protection domain –a thread belongs to a protection domain –a domain is created by a thread – child domain child trusts parent, but NOT vice versa –segment is a set of pages –a thread has a set of capabilities to access segments password capabilities for easy exchange of capabilities between threads ACL is kept in a name server –a thread which has a capability to a segment can attach the segment to the protection domain to which it belongs

15 Opal(2) what about fine grain sharing? –handling protection for fine grains is too much burden on OS –let language handle it use safe language (strongly typed language) Inter-Domain Communication –shared memory for data sharing –portal for code sharing an entry point for a server in a global space that, so any thread can see it a portal is associated with a fixed address where a client request is executed

16 Opal(3) Capabilities and portals –capability = portal id + object address + check field 1.a thread asks the server for capability to access an object 2.the server checks ACL of the object 3.the thread access the object through the portal with handing out the check field the check field indicates the access rights

17 Structuring User Software user software consists of several cooperating domains Set up 1.prepare a parent thread running in one domain 2.the parent thread creates several new domains 3.attach segments to each domain 4.registers a portal for a child domain 5.define a set of procedures associated with a portal

18 Structuring User Software(2) Sharing Mechanism –protected(by capability) procedure call through portal –create objects in a segment that is shared with child domain –generate capabilities (ask the server) for those object –invoke the object through the portal (in the capability) –when the parent pass the capabilities to other children, the siblings are connected through RPC(call through the portal)

19 Linking Differences from private address space –each module(image) starts at different addresses well known modules should always start at the fixed address –module is globally fixed when a segment is allocated a module may be shared by several threads –code is easy to share –stack, heap can be allocated whenever needed by a thread resizing problem

20 Linking (2) –static private data should be prepared for each thread but they are accessed from the same shared code use relocation register –each thread has a unique value for relocation register. –Q: Can you use relative addressing only for all the cases? is there a separate register for this purpose? If there is a register for base address (like GP of MIPS), use it. –modify/remove instructions that updates GP value

21 Linking Implementation Purify –modify code generated from a compiler for correct static private data handling (change all the references to those using relative addressing) –keep the sanity of the base register Resolve –like other linker, resolve cross-module references –no dynamic linking

22 Implementation

23 Discussions heap allocations –several threads allocate heaps in the single address space p1 = malloc(…); some code p2=malloc(…) for private address space, p1 and p2 are contiguous for a single AS, another thread my allocate heap between p1 and p2 –software cannot assume contiguity of p1 and p2 address cloning of Unix fork is not possible –parent and child occupies different ranges of address space –in Unix, they occupy the same range, 0~N

24 Discussions(2) data copy –pointers inside the copied data should be translated –in Unix, copied data can be placed at the same virtual address pointers are correct in the copied data

25 Summary A single address space operating system –new hardware makes it feasible –information sharing is simplified –memory addressing and access control can be separated without loss of protection. Complicates linking and loading –but it can be solved Leaving some protections on applications may jeopardize the protection Page table may be huge

26 Threads (a) Three processes each with one thread (b) One process with three threads

27 The Thread Model (2) Items shared by all threads in a process Items private to each thread

28 The Thread Model (3) Each thread has its own stack

29 Thread Usage (1) A word processor with three threads

30 Thread Usage (2) A multithreaded Web server

31 Thread Usage (3) Rough outline of code for previous slide (a) Dispatcher thread (b) Worker thread

32 Thread Usage (4) Three ways to construct a server

33 Implementing Threads in User Space

34 Implementing Threads in User Space managed by runtime library routines linked into each application program require no kernel intervention efficient – cost < 10* (cost of procedure call) flexible: can be customized to the needs of language or user view a process as virtual processor

35 Implementing Threads in the Kernel

36 Hybrid Implementations Multiplexing user-level threads onto kernel- level threads

37 Hybrid Implementations base: allocate the same number of threads as the number of processors allocated to a job –when a user thread blocks, it wastes a processor –if it allocates more kernel threads than allocated processors, time slicing is needed problems of busy-wait synchronization scheduling of idle user thread summary –the number of kernel thread a job needs changes –the number of processors allocated changes –by the scheduling between jobs –by the degree of parallelism

38 Pop-Up Threads Creation of a new thread when message arrives (a) before message arrives (b) after message arrives

39 Making Single-Threaded Code Multithreaded (1) Conflicts between threads over the use of a global variable

40 Making Single-Threaded Code Multithreaded (2) Threads can have private global variables