Joonwon Leejoon@kaist.ac.kr

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

addressspace of

process A

addressspace of

process A

addressspace of

process A

addressspace of

process A

addressspace of

process A

process Bprocess 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 spacep1 = 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