II. Systems Programming using C (Process Control Subsystem)

(1)

II. Systems Programming using C

(Process Control Subsystem)

(2)

Operating Systems • Prof. Dr. Marc H. Scholl • DBIS • U KN • Summer Term 2009

Intended Schedule

Date Lecture Hand out Submission

0 20.04. Introduction to Operating Systems Course registration Course registration 1 27.04. Systems Programming using C (File Subsystem) 1. Assignment

2 04.05. Systems Programming using C (Process Control) 2. Assignment 1. Assignment

3 11.05. Processes Scheduling 3. Assignment 2. Assignment

4 18.05. Process Synchronization 4. Assignment 3. Assignment 5 25.05. Inter Process Communication 5. Assignment 4. Assignment

6 01.06. Pﬁngstmontag 6. Assignment 5. Assignment

7 08.06. Input / Output 7. Assignment 6. Assignment

8 15.06. Memory Management 8. Assignment 7. Assignment

9 22.06.

Filesystems 9. Assignment 8. Assignment

10 29.06. Filesystems

10. Assignment 9. Assignment 11 06.07. Special subject: Transactional Memory 10. Assignment 12 13.07. Special subject: XQuery your Filesystem

13 20.07. Wrap up session

✏ ^27.07. First examination date First examination date First examination date

✏ 12.10. Second examination date Second examination date Second examination date

130

(3)

Process Control

Subsystem

(4)

!"#$%&'()*&+,*(-.)/ 012'&345

!"#$%"&''('#")"

*+%,-.('#")-/

01$231$"

01$231$"4.#"5"$5+6

!"#$"%&'"("%

)*#+,*#"&'"("%

-."#&'"("%

!"#$"%&'"("%

71#"%4.5&'('#")-8/0%"&.12.3.4"59

:$;<"'''#"5"$5+6'4 .5&'('#")-86#78"..

87$4#7%&.12.3.4"59

.="%>?"$4

@"$31A#5+6 :$;<"'';$4

<5#"%A5+6 B+#"$4:$;<"''4 C;))5+%D1#%;+

:5EE"$5+6 821//"#&8*89"9

85"57#3 5*$*:"5"$49

8.89"+1%0$:9 8;<=9

F"%>?"+-889*#*84"#9 !A;>D-82%78>9 G"$H#"#$"%&"$-82"@%>"-2$%@"$9

!"+5#<"$=$;6$1))"

.('#")15E$5E4.>?+%##'#"AA"-8.3.4"5&8*%%&0$4"#/*8"9 :$;6$1))&%&A%;#?"D

UNIX system architecture (System V)

132

Files Processes

(5)

Program and Processes

• A program is an executable ﬁle

• residing on disk in a directory

• read into memory

• executed by the kernel as a result of one of the six exec(3)

functions.

• An executing instance of a program is called a process.

• Every process has a ‘unique’ numeric identiﬁer called process ID.

• The process ID is always a non-negative integer.

• Although unique, process ID are reused (kernel delays re-usage).

(6)

Running process printing pid

134

(7)

Status information of processes

• man 1 ps describes the user command program /bin/ps

(8)

Obtaining process state with ps(1)

136

(9)

Getting process identifiers

(10)

Operating Systems • Prof. Dr. Marc H. Scholl • DBIS • U KN • Summer Term 2009 138

Virtual Memory

• Each process has its own address space in virtual memory.

• Processes:

• do not know about each other

• (from their perspective) run alone on the machine

• their address spaces are independent from each other

• For inter-process communication special kernel mechanisms

have to be invoked (➝ lecture 5)

(11)

Virtual Memory on Linux

• Memory locations are addressed through pointers.

• As such the natural word size of a processor sets an upper bound for the largest address to reference.

• On 32-bit systems: 2 ³² Bytes = 4294967296 Bytes = 4 GiB

• Often this exceeds the physical memory available and gives name to the term virtual memory.

• Linux divides virtual memory in kernel and user space.

• Each user process has its own

address space from 0 to ^TASK_SIZE.

kernel space ²

³²

^{/ 2}

⁶⁴

kernel space

kernel space _{TASK_SIZE} user space

user space

(12)

Building programs

140

(13)

From Source Code To Executable Code

Translation Steps (multi-phase compilation)

Compilation HLL source code to assembler source code Assembly Assembler source code to object code

Linking Object code to executable code

Compilers and assemblers create object files containing the

generated binary code and data for a source file. Linkers combine multiple object files into one, loaders take object files and load them into memory.

Goal: An executable binary file (a.out)

From high-level language (HLL) source code to executable code, i.e., concrete processor instructions in combination with data.

From source to executable code

(14)

Translation Steps Using gcc(1)

Präprozessor Compiler Assembler Binder

.c/.cc/*.cpp

*.s

*.o

.o/.a

a.out Eingabe-

Ausgabe-

Quellcode C/C++ Assembler-Quellcode

Assembler-Quellcode Objektdatei Ausführbare Datei (= Objektdatei, ladbar)

Objektdatei,

.i/.ii

Vorverarbeiteter

Bibliotheksdatei

dateien

C/C++-Quellcode (ungebunden)

Objektdatei (ungebunden)

Translation step using gcc(1)

142

(15)

Creation Of An Executable File

= Operation

= Eingang oder

= Kommando

(Filename).o

a.out ld

gas Assemblieren

(Filename).s gcc Kompilieren (Filename).c

Object/Library Files

Binden

Ausgang

Creation of an executable file

(16)

Linking An Executable Binary

OBJ1 OBJ2 OBJ3

.data1 .text2 .bss2

.text3 .data3 .bss3

.text1 .bss1

.text1 .text2 .text3 .data1 .data3 .bss1 .bss2 .bss3 Eingabedaten: ungebundene Objektdateien

Verarbeitungsresultat: ausführbare Datei (gebunden, reloziert) Bindung (linking)

OBJtotal

.text: Code

.data: initialisierte Variablen .bss: nicht initialisierte Variablen

!

Each object code (compiled seperately) starts at address 0

!

Linking them together involves

!

centralization of sections

!

relocation of adresses

Linking an executable binary

144

(17)

Typical Program Organisation

A typical program divides naturally in sections

Code machine instructions, should be unmodifiable, size is known after compilation, does not change (.text)

Data

^!

static data

!

initialized (.data) /uninitialized (.bss)

!

constant address in memory

!

permanent life time

!

dynamic data

!

stack or heap

!

storage space not known

!

volatile life time

Program file organization

(18)

Memory Layout

146

(19)

Virtual Memory And Segments

Virtual Memory

!

Whenever a process is created, the kernel provides a chunk of physical memory which can be located anywhere

!

Through the magic of virtual memory (VM), the process believes it has all the memory on the computer

Typically the VM space is laid out in a similar manner:

!

Text Segment (.text)

!

Initialized Data Segment (.data)

!

Uninitialized Data Segment (.bss)

!

The Stack

!

The Heap

(Virtual) Memory Layout

(➝ lecture 8)

(20)

Memory Segments

148

{

(TASK_SIZE)

(21)

Memory Segments

Text Segment. The text segment contains the actual code

(including constants) to be executed. It’s usually sharable, so multiple instances of a program can share the text segment to lower memory requirements. This segment is usually marked read-only so a program can’t modify its own instructions.

Initialized Data Segment. This segment contains global variables which are initialized by the programmer.

Uninitialized Data Segment. Also named .bss (block started by symbol) which was an operator used by an old assembler.

This segment contains uninitialized global variables. All

variables in this segment are initialized to 0 or NULL pointers before the program begins to execute.

Memory segments

(22)

Memory Segments (cont.)

The Stack The stack is a collection of stack frames which we will discuss later. When a new frame needs to be added (as a result of a newly called function), the stack grows downward.

The Heap Dynamic memory, where storage can be (de-)allocated via C’s free(3)/malloc(3). The C library also gets

dynamic memory for its own personal workspace from the heap as well. As more memory is requested “on the fly”, the heap grows upward.

Operating Systems • Prof. Dr. Marc H. Scholl • DBIS • U KN • Summer Term 2009 116 150

Memory segments

(23)

Variable Placement

Variables (outside a function) Globally declared variables go to the Uninitialized Data Segment if they are not initialized, to

Initialized Data Segment otherwise. Necessary for the OS to decide if storage has to be loaded with initialization data from the executable binary.

Variables (inside a function) Implicit assumption of auto, go to The Stack. Declared as static, see above.

Constants (const) Text Segment

Function Parameters Are pushed on The Stack or stored in registers. If pointers are passed, data is elsewhere.

Loading into memory segments

(24)

Variable Placement And Life Time (Code)

int

a ;

/* P e r m a n e n t life time */

static int

b ;

/* dito , but reduced scope */

void

func (

void

) {

char

c ;

/* only for the life time of func () */

/* but 2 x ; visible only in func () */

static int

d ;

/* i ’m unique , exist once at a stable */

/* address , visible only in func () */

}

int

main (

void

) {

int

e ;

/* life time of main () */

int

* pi = (

int

*) malloc (

sizeof

(

int

));

/* newborn */

func ();

free ( pi );

/* RIP , pi points to an invalid address */

return

(0);

}

Operating Systems • Prof. Dr. Marc H. Scholl • DBIS • U KN • Summer Term 2009 118 152

Variable placement, life time, visibility

(25)

Variable Placement And Life Time (Diagram)

t=0: Programmausführung wird gestartet, d.h., Ausführungsum- gebung ist bereits initialisiert t=x: beliebiger Zeitpunkt während der Programmausführung

Code

Daten

Halde (Heap)

Stapel (Stack) Adresse

0

max.

PC(t=0) PC(t=x)

pi

SP(t=0) SP(t=x)

1. Instruktion 2. Instruktion 3. Instruktion 4. Instruktion ...

a b

cpi e

int d

Variable placement in address space

(26)

Multitasking

154

(27)

Multitasking Systems

• In terms of hardware parallelism as much processes may be executed concurrently as processors are available.

• Multitasking systems allow for (apparently) simultaneous execution of multiple processes on a single processor.

• The kernel switches between processes in short intervals to simulate the parallel execution (task switch).

• The kernel decides in what way the computing time is assigned to

different processes (scheduling ➝ lecture 3).

(28)

Processes and Threads

!"#$%$&'(")()*+,-. /*01234

!"#$%"&''('#")"

*+$%+,#",-."$-/01#2+$"34+$+55"5%#6#

■

!"#$%&&%3562002738232192723:;0"<-<.92;<79273-=)3()9)"..23>")*

??@3A2>253()*9)"..362106351BC3:>)255)"<.37<)3.163D26)12;55E562.

??@3()9)"..23517>3F7217"7>2)315*012)63G52C273217"7>2)371BC6H

■

'("%)&3562002732192723:;0"<-56)I792317392.2175".2)3:;0"<-<.92;<793>")J*

??@3K<39021BC2.3()*+255392CL)1923MC)2">53621027351BC3>273:>)255)"<.3<762)217"7>2) 33333<7>3.163D26)12;55E562.

??@3N21723O50"617

■

()+25523<7>3MC)2">53!L77273<762)5BC12>01BC3!.;1712)63P2)>27

??@3A237"BC3D26)12;55E562.32172Q3.2C)2)23>2)3"0023N.;17"61*7273<762)56=6+6

8237<)32173MC)2"> 823.2C)2)23MC)2">5

.2C)2)23()+2552 .2C)2)23()+2552

7<)32173()*+255

7<)3%3MC)2">

789 7!9 7:9

7<)32173()*+255

.2C)2)23MC)2">5

Single Process 7;9

Single Control

Flow

Multiple Processes

Three Control

Flows (Threads)

Single Control

Flow

Multiple Control

Flows (Threads)

• Threads: Parallel running activities inside a process.

• Each thread belongs to dedicated process.

(29)

Pseudo parallel execution !"#$%"&''('#")"

**!"%'%"+,-.$,/"0$$12$3))&"#$%"&**

■

56+2#71620083900:;163;2#")"72)3<2=>62)3#)3()+2;;?3@,>3;2#")"723()A)"..+B>02) CCD3E2F:267120023()+2;;23G!"#$"%&'()+,-."!!"!H

■

I:[email protected]#:6!736:)32162;3@2)3K12)3()A)"..23".30":-263G1.3L16#)+2;;*);M;72.H

45,4$16"'',7,84579

45,4$16"'',:,845:9

45,4$16"'',;,845;9

45,4$16"'',<,845<9

="%#

45>!"+"2?@2 45,4$16"'',7 45,4$16"'',:

45,4$16"'',;

45,4$16"'',<

45,4$16"'',7

?'AB

45,4$16"'',:

4$16"''?)>

'C03+#?@2"@

="%#

4$16"'',7 4$16"'',: 4$16"'',; 4$16"'',<

45D,4$12$3))>

6E0+"$,8!"#$"%&'(#)*+,"9

-."+),//'012'.*'1234 ",%/'012'.*'2154

45!D,4$1C"'',51@#$1+,!+1CF

8GH"$A3+#?@2'I3#"@,I"',4$16"''"'9

task switch

Conceptually:

Each process has its own machine

Time-Multiplexing PC: program counter

PCB: Process Control Block

time

(30)

!"#$%$&'(")()*+,-. /*01234

!"#$%"&''('#")"

$+,"''-)'./01#-23"24-2546!

$+,"''47 $+,"''48

9"%#

64%24:67;4'%./"$24

**:68;4%2464<+=%"$"24**

64%24:68;4'%./"$24 **:67;4%2464<+=%"$"24**

$+,"''41>-?#40-?46@

*$+,"''41>-?#42%./#

6!A4$+."''46+2#$+14!1+.<

6A4$"01"$4645"$46*@

**:67;B4:68;A4C%$#-"11"46 5"$4$+,"''"474D48**

674D4684'%254%24*6!74D

*6!84"2#/01#"2

**:*$+,"''C"$E01#-23'50#"2;**

Task Switch and PCB

(31)

!"#$%"&''('#")"

*&+,-./0,'"12"%1"'23$45"''"'

56"713892:2;7#<"72;=321;273()*+27727

>;?2)7@<21A:")23(<"72;B

■

9"A2;3A273()*C)"..73DE39"A2#<"72F

■

G?")?2;3A273()*C)"..73DE3G?")?#<"72F

■

()*C)"..":0"6-3DE3H2?)12:7#<"72F

■

()*C)"..:22;A1C6;C3DE3I2).1;12)6;C7#<"72F

6&7"8#9,#"%.4$),#

■

9"A:")23J"?212;3.K772;321;2.3L)C2C2:2;2;3/)."?32;?7#)2@<2;

MMN3O2)21;:")6;C3+P17@<2;3H2?)12:77Q7?2.36;A3R##01!"?1;S3P20@<23T;<"0?23P31;3A2) 33333"67-K<):")2;3J"?213":C202C?371;A

MMN3U1;3:27?1..?273H2?)12:77Q7?2.3!21;321;3A2)3.2<)2)23/)."?236;?2)7?K?+2;

Process Life Cycle

kann

(32)

Process Termination

(33)

!"#$%"&''('#")"

*$+,"''#"$)%-%"$.-/

■

/).25362)3()+2778225619:59;

<%=3>*)."023?225619:593<-)21@10019=

<&=3A)+21B1923?225619:59382136:)CD3()+277372087B32)!"55B2.3/2D02)3<-)21@10019=

<$=3A)+21B1923?225619:5938213!"B"7B)#D"02.3/2D02)32)!"55B36:)CD3 333333EF7B2.3<:5-)21@10019=

<G=3H2).1512):5936:)CD3"562)253()*+2773<:5-)21@10019=

>?;3IJ:-197B2)3/"00;3<%=3>*)."023?225619:59

■

K156#)+277230":-253@21B2)L3@2553M0B2)5#)+2773B2).1512)B

<910B3-N)3O51P3:563Q156*@7L35:)3826159B3-N)3"562)23?2B)12877F7B2.2=

Process Termination

161

(34)

Eight way for a process to terminate

• Normal termination

• Returning from main

• Calling exit(3)

• Calling _exit(2) (POSIX.1) or _Exit(3) (ISO C)

• Return of the last thread from its start routine

• Calling pthread_exit(3) from the last thread

• Abnormal termination

• Calling abort(3)

• Receipt of a signal ( ➝ lecture 5)

• Response of the last thread to a cancellation request

(35)

Normal termination details

• Normal termination

• Returning from main

• Equivalent to calling exit(3)

• Calling exit(3)

• closes/ﬂushes all standard I/O streams

• calls all exit handlers registered with atexit(3)

• ISO C does not deal with ﬁle descriptors, multiple processes (parents

and children), and job control, as such its deﬁnition is incomplete for

UNIX systems.

(36)

Normal termination details

• Calling _exit(2) (POSIX.1) or _Exit(3) (ISO C)

• ISO C deﬁnes _Exit(3) to provide a way for a process to terminate without exit or signal handlers.

• Whether standard I/O streams are ﬂushed is system dependent.

• On UNIX systems _exit(2) and _Exit(3) are synonymous and do not ﬂush standard I/O streams. The _exit(2) function is called by exit(2) and handles the UNIX system-speciﬁc details

• Return of the last thread from its start routine

• The return value of the thread is not used as the return value of the process. When the last thread returns, the process exits with 0.

• Calling pthread_exit(3) from the last thread

• Same as above

164

(37)

Starting and terminating a C program

(38)

Process Creation

(39)

!"#$%"&''('#")"

*+,+,-.$/0"''"$0"12132-134-5"$)%3%"$132

■

425)3216-"7523489:2.23;<10:3-=)3>12023!"#!$$!$%&'&(!"&?@

A0023()+299232B19:12)263>63A6-"6<3"63C6D30"C-2632E1<F3D,5,39*0"6<23489:2.30GC-:

■

A00<2.2162)23489:2.23;)!!+,-./0+/1&!%&'&(!"&?@*

()*+29923E2)D263H213I2D")-32)+2C<:3C6D3<202<26:01753E12D2)3:2).1612):

■

AC90J926D23K)21<619923-=)3()*+2992)+2C<C6<@

;%?3489:2.9:"):3;L61:1"01912)C6<?

;&?3489:2."C-)C-3+C)3()+2992)+2C<C6<3DC)7531)<26D2162630"C-26D263()+299

;$?3I26C:+2)"6-)D2)C6<3+C.34:"):26321629362C263()+299293;A##01!":1*699:"):?

;M?3AC90J9C6<32162934:"#20"C-:)"<93;#,(23%41#?

Process Creation

(40)

!"#$%$&'(")()*+,-. /*0123%%

!"#$%"&''('#")"

*+',%'#,"%-,.$/0"''1

4156738293()*:)"..2;7<15!02)93=1;3>?@

■

**>A():)"..B38,6,3main()A/C;!71;**

4156738293D27)12E99F972.93=G8)299)"C.E202:C;:?@

■

H"72;E2)21563=1;!0,347"5!3C;83I2"#?

■

():)"..582E2)2156

■

H"72;97)C!7C)3+C)3()+2992J2)<"07C;:38C)5638"93 D27)12E99F972.3=!"#$%!&'()**%"'+,&'-%#-'(./$%01#1* *2%!34%5!&'0)**.)++6+7/*

*2%8.,6)--)&%!&'0)**06,9+:

*2%!&'0)**.'+,);,*

G8)299)"C.

()+299A 582 ()*+299A 8"72;

(>D

What is a process?

168

kernel space ²

³²

^{/ 2}

⁶⁴

kernel space

kernel space kernel space

TASK_SIZE

user space user space

0 PCB

argv, env

linux/sched.h: struct task_struct

(41)

Process Hierarchy

(42)

!"#$%$&'(")()*+,-. /*0123$$

!"#$%"&''('#")"

*+,+-./$01"''2%"$3$42%".5!"%'6%"78.9:%;<

%:%# /=>?@

/=>?A

B"##( B"##( B"##( '2 B"##(

C%:D '2

UNIX process hierarchy

170

(43)

UNIX system start (simplified)

• Bootstrap loads system code to memory.

• Initialization of internal kernel data structures.

• Mount root ﬁlesystem

• Environment for the ﬁrst process is created.

• System code becomes process with PID=0

• Process 0 forks and creates process 1 (kernel space)

• Process 1 creates environment in user space and turns over

• PID=0 (kernel space), PID=1 (user space)

(44)

UNIX system start (simplified)

• Process 1 uses exec on, e.g., /sbin/init & becomes init

• init is responsible for bringing up a UNIX system after the kernel has been bootstrapped. It usually reads system-dependent initialization ﬁles (such as /etc/rc* or /etc/inittab , /etc/init.d ) and brings the system to a certain state, such as multiuser. For instance, the

terminals for users to login ( getty ) are started.

• It is a normal user process running with superuser privileges.

• init never dies.

• Meanwhile, process 0 starts kernel services in kernel space and ﬁnally becomes the swapper, i.e., the scheduler process.

172

(45)

Process Hierarchy on Linux

• Linux has a hierarchical process schema, i.e., each process is

connected to its parent process.

• The kernel starts init as ﬁrst process.

• The process hierarchy is a result of the process creation used on UNIX systems:

• fork(2)

• exec(3) family

(46)

!"#$%$&'(")()*+,-. /*0123%$

!"#$%"&''('#")"

*$+,"'''#-$#.+$)"/

*$+,"''0"$"%/%12/1'.+$)"/

**3456$+,"''0"$7"##2/1 3!56$+,"''0"$1-&"82/1 3956*$+,"''"$,"212/1**

45"16 -*)! 4)2"72

**3:56$+,"''0"$"%/%12/1 3;56$+,"''#$".."/**

8*16 2917 :"17 2917

Process creation and joining

174

(47)

!"#$%"&''('#")"

('#")+,-$,-".-/$.0$12"''3456$"+73#+$#

*('#")+,-$,-".-/$.0$12"''3456$"+738"$"%9%:,9:

;9%<30$12"''" **0=*>?356$"+7' @%971A'30$12"''" @%971A'356$"+7'**

B6+%9 exec() 5 5 5

-1$C fork() 5 5 5

B$"+#" 5 pthread_create() CreateProcess() CreateThread()

;9%<30$12"''" **0=*>?356$"+7' @%971A'30$12"''" @%971A'356$"+7'**

D1%9 wait()63waitpid() pthread_join() 5 5

A+%# 5 5 WaitForSingleOb-

ject() WaitForSingleOb-

ject()

Related system calls

(48)

!"#$%$&'(")()*+,-. /*0123%4

!"#$%"&''('#")"

*"%#"$+,&"-./0-1,#"0-,0-0"2"-3$/4"''"567$",8'

5670189!21:2;<

■

=2)2)>?;7

■

@21:2)7">23A>2)3B":2;#?--2)

■

C;1:1"0#")".2:2)3-A)3;2?2;3()*+2DD

■

@21:2)7">23A>2)3:2.#*)E)23B":21F2;G

H21D#12023!*;!)2:2)3C.#02.2;:12)?;72;31;3H2:)12>DDID:2.2;<

90%:;3$/4"''" 3<=>?;67$",8' *%08/@';

3$/4"''"

*%08/@';

67$",8' A"$"$&20+ fork() J CreateProcess() J

>0#"$B$/4C/)D popen() J J J

>0%#%,EB,$,)D J pthread_create() J CreateThread()

Initialization of processes/threads

176

(49)

!"#$%"&''('#")"

*+,+-./"$"$&012.01#"$.3$45"''"1

/"$"$&012.&"%.61%783$45"''"1 421.3/*)!1567

■

8923:593;#123"002)3<"=253>?3!"#$%"&%#'()+%!"()%,-'.)@*

■

<"=2192A!)1#=)25B39123C53D0=2)5#)+2AA3E2+625

■

F21=2)23D1625AGH"-=25B3+,4,3:A2)I6)*:#319B3J.62E:56AC")1"E025B3K)E21=AC2)+21GH51AB

;5=)00=2).15"03:AL, 421.38H"151567

■

(M<3:593((M<

■

<"=2192A!)1#=)25B39123!/"0)1"1)2)!351GH=362A2=+=3H"E25

>N473!/"0)1"1)2)!3L1)93A="59")9.OAA163E21.3<"=21P--525351GH=362A2=+=@3*

■

F21=2)23D1625AGH"-=25B3+,4,3:A2)I6)*:#319B3J.62E:56AC")1"E025B3K)E21=AC2)+21GH51AB

;5=)00=2).15"03:AL,

Inheritance with fork / exec

(50)

Forking processes

(51)

!"#$%"&''('#")"

+,+-.$/0"''"-12#"$-32%45-.$/0"''6"$78&"9127-:;/$<%27=

■

()+25562)7"8209:73;3()+25537"820<351=>3"9-31:3+?213@:<)00-0A5523.1<37021=>2.3B*C2

■

()1:+1#8215#120D

int main() {

int k, status;

pid_t pid;

k=fork();

if (k == 0) {

... // Anweisungen, die nur Kindprozess

... // ausführen soll

exit(0); // Kindprozess terminiert

}

else {

... // Anweisungen, die nur Elternprozess

... // ausführen soll

pid = wait(&status); // Auf Ende des Kindprozesses warten exit(0);

}

Forking processes on UNIX

(52)

!"#$%$&'(")()*+,-. /*0123%4

!"#$%"&''('#")"

$+,"''-"$./&"012.343$+,"''-"$5+66"012.37/&38+$9:;18$18<

main() {

int k, status;

pid_t pid;

k=fork();

if (k == 0) { ...

...

exit(0);

}

else { ...

...

pid = wait(&status);

} } main()

{

int k, status;

pid_t pid;

k=fork();

if (k == 0) { ...

...

exit(0);

}

else { ...

...

pid = wait(&status);

} }

=0#"$26$+,"'' >%256$+,"'' *$%2,%6/&0/18

5"16 2716 -*)!

#")286 9:10;

Forking processes on UNIX

180

(53)

!"#$%"&''('#")"

*+%,-.('#")/01$01"213$24$56"''"$6"070+720+829"$)%+%"$0+7

system call 42567)2189:;3<!"#$%&'()*+,$+)&-&$./)0$1(/2(*$3(4&+=

pid = fork () >)+29;?321:2:3@1:A#)*+255B3A2)31A2:?15673.1?3A2.3>0?2):#)*+255315?3<;18?3 C31.3@1:A#)*+25539:A335%6$7#89&++$):&/')!)9(')8/31.3>0?2):#)*+2553 +9)D6!E3-"0053/2702)B3A"::3FD6!;"82G2)?3H%=

pid = wait (&statloc) I")?2?3"9-3A123J2).1:12)9:;31);2:A21:253@1:A#)*+25525

<;18?3(KL3A253@1:A#)*+2552538+G,3C31.3/2702)-"003+9)D6!E3

+95M?+01673FD6!;"823A253422:A1;9:;55?"?9539:A3FD6!;"82G2)?53A253

@1:A#)*+255253.1??2053statloc=

pid = waitpid (pid, &statloc, options)

I")?2?3"9-3A123J2).1:12)9:;321:253825?1..?2:3@1:A#)*+25525,3N#?1*:53 51:A3+,4,3!21:3I")?2:B3-"0053@1:#)*+2553:*673:167?3822:A2?,

<;18?3(KL3A253@1:A#)*+2552538+G,3C31.3/2702)-"003+9)D6!E3

+95M?+01673FD6!;"823A253422:A1;9:;55?"?9539:A3FD6!;"82G2)?53A253

@1:A#)*+255253.1??2053statloc=

s = execve (name, argv, environp)

>)52?+?30"9-2:A2:3()*+2553A9)67321:2:3:292:3()*+2553<:292)3()*+2553 2)8?3O*:3"0?2.3()*+255=,3<P18?3H%38213/2702)3+9)D6!B35*:5?3!21:23FD6!H

;"82=

Q67?9:;R3253;18?3S302167?3O2)56712A2:23T")1":?2:3A125253UV5?2."9-)9-5W exit (status) J2).1:12)?3"9-)9-2:A2:3()*+25539:A35?200?3FD6!;"82G2)?3-D)342?)12855VH

5?2.382)21?3<G1)A3D82)3wait() /3waitpid()3A2.3>0?2):#)*+2553

Process system calls in a nutshell

(54)

The fork(2) system call

• PID is returned to parent, because a process can have more than one child, and there is no function that allows a

process to obtain the PID of its children.

• Returning 0 to the child is apt, since PID=0 is reserved by the kernel, so it’s not possible for 0 to be the PID of a child.

• The child can always obtain the PID of its parent, calling

getppid(2) .

(55)

!"#$%"&''('#")"

**!""+%,-,'./-+/0-'123$-,''#4#-'**

■

41)352-1612)263512723829)1--23:123-*09;<

!""#$%&'#&(())'(<3=)."03;2).1612);3>+:,3-2?02)?"-;3@+,8,3A)+21;192)3()+277">>)BC?D **+,-.&/"0"1)<3EB-)B-#")".2;2)352)3exit()F/B6!;163@5"73:"73G165#)*+2773+B)HC!F** 92>263:100D

■

41232)?"0;263:1)3512723I6-).";16263A*.3JK7;2.3+B927;200;L

**FFM382152342);23!.>1612);3A1"3N7;";0COF(")".2;2)35273wait()Pwaitpid()FEB-)B-7** FFM3N7;";0*CO3+219;3"B-321623720>7;352!0")12);23Q")1">023N7;";B7O3@E5)277)2-2)26+D

FFM3N7;";B7O3!"663.1;;2073A)52-1612);2)3R"!)73"B792:2);2;3:2)526<

**33333WIFEXITED(status)<3STUV3-H)36)."0W3/EXJV3-H)3A)+21;193">92>)*C?26**

**33333WEXITSTATUS(status)<3X12-2);35263THC!9">2:2);3@-"00736*)."023S2).1612)B69D**

■

8217#120<

pid_t pid;

int status;

pid = wait(&status);

if (WIFEXITED(status))

Obtaining termination status

(56)

!"#$%$&'(")()*+,-. /*0123%4

!"#$%"&''('#")"

$+,"'''#-$#.)%#./"$,0"%1"2.34+)&%"5$+&6")7

fork()

wait()

fork()

exit() **8-66.397:35062)7#)+28839")6263 8-66.3!7:3:17;#)+288362).1712)6<3**

=216

=*.>12?

@*;2A

B"627A

(

_C

(

_C

(

_D

(

_C

(

_C

(

_C

(

_D

(

_C

(

_D

(

_D

(

_C

(

_C

"E-357;23;283:17;#)+28828 >2F)35062)7#)*+28839")626

exit() wait()

#)*+288

Zombie Processes

184

(57)

!"#$%"&''('#")"

*+)&%","$-%./"$0.12)%##"3'24.5"36$+7"''

■

526)1--27

!"#$%&38391:;#)+2<<=3;2)31.3>?<@2.3A21@2)02B@=3BAC032)3@2).1:12)@3C"@*

'(%)&+",-.(/038391:;#)+2<<=3;2<<2:3D0@2):#)+2<<3:[email protected])32F1<@12)@*

91:;% 91:;%

91:;& 91:;&

fork()

D0@2) D0@2) D0@2) D0@2)

G%H G&H G$H GIH

91:;%

91:;&

wait()J exit() D0@2)

GKH

L"EC3>EC)1@@3G$H7

L"EC3>EC)1@@3GIH7

91:;&31<@391:;3M*:391:;%

91:;%31<@391:;3M:3D0@2) 91:;&31<@3D:!203M:3D0@2)

D0@2)3C"@3!21:2391:;2)3.2C) 91:;&31<@391:;3M:31:1@N ()+2<<3G";*#@12)@23O"1<2H

Zombie prevention

(58)

Process chaining

(59)

!"#$%"&''('#")"

*$+,"''#-$#.)%#./"$0"##123.456-%2%237

■

45365173.1839253:3272;<=>?@-)@-253)2"01A12)8

■

6582)A;B1292392)3:3272;<=>C")1"5825D3?)83@593?5+"B0392)3?@-)@-#")".282)

<15392)3/@5!8153A1593"0023E021;BF39,B,3()+2AAG2)!288@5E=

8+9":

;-#"2:

/"$0"##123

<"%#

*₌ *₌

*_!

execve()

Process chaining

(60)

Tab. 3–5 Unix-Systemaufrufe execl(), execle(), execlp() und execv() ok = execl(pathname, arg0, arg1, ..., NULL);

Zweck: Startet ausführbare Datei als neuen Prozess, ersetzt (terminiert) damit laufenden Prozess Parameter:

const char * pathname: Pfadname der Datei

const char * arg0, * arg1, ..: 1./2./.. Kommandozeilenargumente (Liste mit NULL abschließen) Rückgabewert int: keine Rückkehr falls okay; im Fehlerfall Rückgabe von -1

ok = execle(pathname, arg0, arg1, ..., NULL, envp[]);

const char * arg0, * arg1, ..: 1./2./.. Kommandozeilenargumente (Liste mit NULL abschließen) const char * envp[]: Adresse einer neuen Umgebungsvariablenliste

Rückgabewert int: keine Rückkehr falls okay; im Fehlerfall Rückgabe von -1 ok = execlp(filename, arg0, arg1, ..., NULL)

const char * filename: Dateiname (Suchpfad entsprechend Umgebungsvariable PATH)

ok = execv(pathname, argv[]);

const char * argv[]: Adresse einer Liste mit allen Kommandozeilenargumenten Rückgabewert int: keine Rückkehr falls okay; im Fehlerfall Rückgabe von -1

exec(3) family

188

(61)

Tab. 3–5 Unix-Systemaufrufe execl(), execle(), execlp() und execv() ok = execl(pathname, arg0, arg1, ..., NULL);

ok = execle(pathname, arg0, arg1, ..., NULL, envp[]);

const char * arg0, * arg1, ..: 1./2./.. Kommandozeilenargumente (Liste mit NULL abschließen) const char * envp[]: Adresse einer neuen Umgebungsvariablenliste

Rückgabewert int: keine Rückkehr falls okay; im Fehlerfall Rückgabe von -1 ok = execlp(filename, arg0, arg1, ..., NULL)

const char * filename: Dateiname (Suchpfad entsprechend Umgebungsvariable PATH)

ok = execv(pathname, argv[]);

const char * argv[]: Adresse einer Liste mit allen Kommandozeilenargumenten Rückgabewert int: keine Rückkehr falls okay; im Fehlerfall Rückgabe von -1

ok = execve(pathname, argv[], envp[]);

Zweck: Startet ausführbare Datei als neuen Prozess, ersetzt (terminiert) damit laufenden Prozess Parameter:

const char * pathname: Pfadname der Datei

const char * argv[]: Adresse einer Liste mit allen Kommandozeilenargumenten const char * envp[]: Adresse einer neuen Umgebungsvariablenliste

Rückgabewert int: keine Rückkehr falls okay; im Fehlerfall Rückgabe von -1 ok = execvp(filename, argv[]);

Zweck: Startet ausführbare Datei als neuen Prozess, ersetzt (terminiert) damit laufenden Prozess Parameter:

const char * filename: Dateiname (Suchpfad entsprechend Umgebungsvariable PATH) const char * argv[]: Adresse einer Liste mit allen Kommandozeilenargumenten

exec(3) family

(62)

Differences among the exec functions

190

(63)

main function

(64)

Program Startup

Prototype for the main function

! The function called at program startup is named main

! It shall be defined with a return type of int

! And either with no parameters:

int main ( void );

! Or with two parameters:

int main ( int argc , char * argv []);

284 Operating Systems • Prof. Dr. Marc H. Scholl • DBIS • U KN • Summer Term 2009

The main function

192

(65)

Constraints For main Function

Terminology (though any names may be used)

! argc stands for argument count

! argv stands for argument vector

If argc and argv are declared

! The value of argc shall be nonnegative

! argv[0] represents the program name or argv[0][0] shall be the null character if the program name is not available

! argv[1] to argv[argc-1] represent program parameters

! argv[argc] shall be a NULL pointer

Constraints of main function

(66)

Command-line Arguments

! When a program is executed, the process that does the exec can pass command-line arguments to the new program

! Normal operation for UNIX system shells argv:

NULL

echo\0 hello,\0 world\0

286 Operating Systems • Prof. Dr. Marc H. Scholl • DBIS • U KN • Summer Term 2009

main: Argument vector

194

(67)

Environment

! Each program is also passed an environment list

! Like the argument list, it is an array of character pointers

! Each pointing to a null-terminated C string

! The address of the array is contained in a global variable:

extern char ** environ ;

environ:

NULL

HOME=/home/holu\0 SHELL=/bin/ksh\0 PS1=\w \ $\0

Environment

(68)

Environment (cont.)

Terminology

! environ is called environment pointer

! The array of pointers is the environment list

! The strings they point to are the envoronment strings

! By convention, name=value string are used

Historical third argument to main (not ISO C)

int main ( int argc , char * argv [] , char * envp );

! Most UNIX systems have provided a third argument to main

! ISO C specifies main with two arguments

! Posix.1 specifies environ to be used instead of 3rd arg

Environment (cont.)

196

(69)

Echo Command-line Arguments

# include < stdio .h >

int

main ( int argc , char * argv []) {

int i ;

/* for ( i = 0; argv [ i ] != NULL ; i ++) */

for ( i = 0; i < argc ; i ++)

printf ( " argv [% d ]: ! % s \ n " , i , argv [ i ]);

return (0);

}

$ ./ a. out -a 1 -arg2 -- arg3 argv [0]: ./ a . out

argv [1]: -a argv [2]: 1

argv [3]: - arg2

Echo command-line arguments

(70)

Building a shell

198

(71)

!"#$%"&''('#")"

*+,+-./012#%31'4"%'".5"$.61%789:";;

int main () {

char kdo[100];

pid_t pid;

int status;

while(1) {

printf("$>");

gets(kdo);

pid = fork();

if (pid==0)

execl(kdo,NULL);

else

wait(&status);

} }

56738"93:;2-)"<.2=>3+21<>3=?)3;12362-2@091=>2)#)2>">1=3A;,@,3!21=23B2)")C21>?=<

333333321=<2C"?>2)3D@200E62-2@023?=;3!21=23D!)1#>1=>2)#)2>">1*=F

(Very) basic sketch of a shell

☠

(72)

!"#$%$&'(")()*+,-. /*0123&4

!"#$%"&''('#")"

*+,-#%.,'/"%'"01"$023"44

■

562003738.."9:19;2)#)2;2)373()+2<<31.3=29>;+2).:><

■

8.."9:?2)")@21;>9A3BC9:0*<<D6021-2EF

B%E3C1902<2938.."9:+21023"@35;"9:"):219A"@23BC19A"@232:1;12)@")E B&E38.."9:19;2)#)2;";1*93B9"D63G21029"@<D60><<3.1;3H)2;>)9IE

B$E3C19A2@">;2)3=2-2603B!"#$%&#'()++,'-EJ* 33333KKI3L"F3M><-N6)>9A3:>)D63562003<20@<;

BOE3/"00<391D6;3B$EF35!)1#;:";21J

33333KKI3L"F3M@")@21;293:2)35!)1#;@2-2602

B4E3/"00<391D6;3BOEF35;");293"0<32P;2)92<38.."9:3B"><-N6)@")23Q";21E

How a shell (basically) works ...

200

(73)

!"#$%"&''('#")"

*+",,-./0'12+$&3$".43#"%.'#3$#"5

■

56")637)82)9):;8#)+2<<=

■

56")63>1;62)9):;8#)*+2<<=

??@35A2003B")6263;1CA63":-3D;82382<3E1;8#)+2<<2<3F-GA)63-)631;3E*..";8H2)")I216:;9J

'+

16$789

8:9

'+

;)<

8=9

">";.;)<

8?9

!"#$%&

'+

'()+* '()+*

!"#$%& !"#$%&

Start up of an executable

(74)

Next lecture/tutorial slots

• Next lecture:

• Process Scheduling

• Mo, 04.05., 12:00 - 14:00, C 252 (new room!)

• Next tutorial:

• Introduction to the C Programming Language Part II

• Tomorrow, Tue, 28.04., 16:00 - 18:00, C 252

• Slides:

http://www.informatik.uni-konstanz.de/

arbeitsgruppen/dbis/lehre/operating-systems/

• Have fun and see you next week!

202

II. Systems Programming using C (Process Control Subsystem)

II.

Systems Programming using C

(Process Control Subsystem)

Intended Schedule

Date Lecture Hand out Submission

0 20.04. Introduction to Operating Systems Course registration Course registration 1 27.04. Systems Programming using C (File Subsystem) 1. Assignment

2 04.05. Systems Programming using C (Process Control) 2. Assignment 1. Assignment

3 11.05. Processes Scheduling 3. Assignment 2. Assignment

4 18.05. Process Synchronization 4. Assignment 3. Assignment 5 25.05. Inter Process Communication 5. Assignment 4. Assignment

6 01.06. Pﬁngstmontag 6. Assignment 5. Assignment

7 08.06. Input / Output 7. Assignment 6. Assignment

8 15.06. Memory Management 8. Assignment 7. Assignment

9 22.06.

Filesystems 9. Assignment 8. Assignment

10 29.06. Filesystems

10. Assignment 9. Assignment 11 06.07. Special subject: Transactional Memory 10. Assignment 12 13.07. Special subject: XQuery your Filesystem

13 20.07. Wrap up session

✏ 27.07. First examination date First examination date First examination date

✏ 12.10. Second examination date Second examination date Second examination date

Process Control

Subsystem

!"#$%"&''('#")"

*+%,-.('#")-/

UNIX system architecture (System V)

Files Processes

Program and Processes

• A program is an executable ﬁle

• residing on disk in a directory

• read into memory

• executed by the kernel as a result of one of the six exec(3)

functions.

• An executing instance of a program is called a process.

• Every process has a ‘unique’ numeric identiﬁer called process ID.

• The process ID is always a non-negative integer.

• Although unique, process ID are reused (kernel delays re-usage).

Running process printing pid

Status information of processes

• man 1 ps describes the user command program /bin/ps

Obtaining process state with ps(1)

Getting process identifiers

Virtual Memory

• Each process has its own address space in virtual memory.

• Processes:

• do not know about each other

• (from their perspective) run alone on the machine

• their address spaces are independent from each other

• For inter-process communication special kernel mechanisms

have to be invoked (➝ lecture 5)

Virtual Memory on Linux

• Memory locations are addressed through pointers.

• As such the natural word size of a processor sets an upper bound for the largest address to reference.

• On 32-bit systems: 2 32 Bytes = 4294967296 Bytes = 4 GiB

• Often this exceeds the physical memory available and gives name to the term virtual memory.

• Linux divides virtual memory in kernel and user space.

• Each user process has its own

address space from 0 to TASK_SIZE.

kernel space 2

/ 2

kernel space

kernel space

kernel space TASK_SIZE user space

user space

Building programs

From Source Code To Executable Code

Translation Steps (multi-phase compilation)

Compilation HLL source code to assembler source code Assembly Assembler source code to object code

Linking Object code to executable code

Compilers and assemblers create object files containing the

generated binary code and data for a source file. Linkers combine multiple object files into one, loaders take object files and load them into memory.

Goal: An executable binary file (a.out)

From high-level language (HLL) source code to executable code, i.e., concrete processor instructions in combination with data.

From source to executable code

Translation Steps Using gcc(1)

Präprozessor Compiler Assembler Binder

*.c/*.cc/*.cpp

*.s

*.s

*.o

*.o/*.a

✏ ^27.07. First examination date First examination date First examination date

• On 32-bit systems: 2 ³² Bytes = 4294967296 Bytes = 4 GiB

address space from 0 to ^TASK_SIZE.

kernel space ²

^{/ 2}

kernel space _{TASK_SIZE} user space

.c/.cc/*.cpp

.o/.a

.i/.ii