CS 3214Computer Systems

Godmar Back

Lecture 13

Announcements

• Project 3 milestone due Oct 8• Have still not heard from everybody

regarding SVN• Exercise 6 handed out

CS 3214 Fall 2010

THREADS AND PROCESSESPart 1

CS 3214 Fall 2010

CS 3214 Fall 2010

A Context Switch Scenario

Process 1

Process 2

Kernel

user mode

kernel mode

Timer interrupt: P1 is preempted, context switch to P2

Timer interrupt: P1 is preempted, context switch to P2

System call: (trap): P2 starts I/O operation, blocks context switch to process 1

System call: (trap): P2 starts I/O operation, blocks context switch to process 1

I/O device interrupt:P2’s I/O completeswitch back to P2

I/O device interrupt:P2’s I/O completeswitch back to P2

Timer interrupt: P2 still hastime left, no context switch

Timer interrupt: P2 still hastime left, no context switch

Bottom Up View: Exceptions

• An exception is a transfer of control to the OS in response to some event (i.e., change in processor state)

User Process OS

exceptionexception processingby exception handler

exception return (optional)

event currentnext

CS 3214 Fall 2010

CS 3214 Fall 2010

Reasoning about Processes:Process States

• Only 1 process (per CPU) can be in RUNNING state

RUNNINGRUNNING

READYREADYBLOCKEDBLOCKED

Processmust waitfor event

Event arrived

Schedulerpicks process

Processpreempted

User View

• If process’s lifetimes overlap, they are said to execute concurrently– Else they are sequential

• Default assumption is concurrently• Exact execution order is unpredictable

– Programmer should never make any assumptions about it

• Any interaction between processes must be carefully synchronized

CS 3214 Fall 2010

CS 3214 Fall 2010

fork()#include <unistd.h>#include <stdio.h>

intmain(){ int x = 1;

if (fork() == 0) { // only child executes this printf("Child, x = %d\n", ++x); } else { // only parent executes this printf("Parent, x = %d\n", --x); }

// parent and child execute this printf("Exiting with x = %d\n", x);

return 0;}

#include <unistd.h>#include <stdio.h>

intmain(){ int x = 1;

if (fork() == 0) { // only child executes this printf("Child, x = %d\n", ++x); } else { // only parent executes this printf("Parent, x = %d\n", --x); }

// parent and child execute this printf("Exiting with x = %d\n", x);

return 0;}

Child, x = 2Exiting with x = 2Parent, x = 0Exiting with x = 0

CS 3214 Fall 2010

The fork()/join() paradigm

• After fork(), parent & child execute in parallel– Unlike a fork in the road, here we

take both roads• Used in many contexts• In Unix, ‘join()’ is called wait()• Purpose:

– Launch activity that can be done in parallel & wait for its completion

– Or simply: launch another program and wait for its completion (shell does that)

Parent:fork()

Parent:fork()

Parent:join()

Parent:join()

Parentprocessexecutes

Parentprocessexecutes

Childprocess executes

Childprocess executes

Childprocess

exits

Childprocess

exits

OS notifies

CS 3214 Fall 2010

fork()#include <sys/types.h>#include <unistd.h>#include <stdio.h>

int main(int ac, char *av[]) { pid_t child = fork(); if (child < 0) perror(“fork”), exit(-1); if (child != 0) { printf ("I'm the parent %d, my child is %d\n", getpid(), child); wait(NULL); /* wait for child (“join”) */ } else { printf ("I'm the child %d, my parent is %d\n", getpid(), getppid());

execl("/bin/echo", "echo", "Hello, World", NULL); }}

#include <sys/types.h>#include <unistd.h>#include <stdio.h>

int main(int ac, char *av[]) { pid_t child = fork(); if (child < 0) perror(“fork”), exit(-1); if (child != 0) { printf ("I'm the parent %d, my child is %d\n", getpid(), child); wait(NULL); /* wait for child (“join”) */ } else { printf ("I'm the child %d, my parent is %d\n", getpid(), getppid());

execl("/bin/echo", "echo", "Hello, World", NULL); }}

fork() vs. exec()

• fork():– Clone most state of parent, including memory– Inherit some state, e.g. file descriptors– Keeps program, changes process– Called once, returns twice

• exec():– Overlays current process with new executable– Keeps process, changes program– Called once, does not return (if successful)

CS 3214 Fall 2010

exit(3) vs. _exit(2)

• exit(3) destroys current processes• OS will free resources associated with it

– E.g., closes file descriptors, etc. etc.• Can have atexit() handlers

– _exit(2) skips them• Exit status is stored and can be retrieved by

parent– Single integer– Convention: exit(EXIT_SUCCESS) signals

successful execution, where EXIT_SUCCESS is 0CS 3214 Fall 2010

wait() vs waitpid()

• int wait(int *status)– Blocks until any child exits– If status != NULL, will contain value child

passed to exit()– Return value is the child pid– Can also tell if child was abnormally

terminated• int waitpid(pid_t pid, int *status, int options)

– Can say which child to wait forCS 3214 Fall 2010

If multiple children completed, wait() returns them in arbitrary order– Can use macros WIFEXITED and WEXITSTATUS to get

information about exit status

void fork10(){ pid_t pid[N]; int i; int child_status; for (i = 0; i < N; i++)

if ((pid[i] = fork()) == 0) exit(100+i); /* Child */

for (i = 0; i < N; i++) {pid_t wpid = wait(&child_status);if (WIFEXITED(child_status)) printf("Child %d terminated with exit status %d\

n", wpid, WEXITSTATUS(child_status));

else printf("Child %d terminate abnormally\n", wpid);

}}

Wait Example

CS 3214 Fall 2010

Observations on fork/exit/wait• Process can have many children at any point in time• Establishes a parent/child relationship

– Resulting in a process tree• Zombies: processes that have exited, but their parent hasn’t

waited for them– “Reaping a child process” – call wait() so that zombie’s resources

can be destroyed• Orphans: processes that are still alive, but whose parent has

already exited (without waiting for them)– Become the child of a dedicated process (“init”) who will reap

them when they exit• “Run Away” processes: processes that (unintentionally)

execute an infinite loop and thus don’t call exit() or wait()CS 3214 Fall 2010

Unix File Descriptors

• Unix provides a file descriptor abstraction• File descriptors are

– Small integers that have a local meaning within one process

– Can be obtained from kernel • Several functions create them, e.g. open()

– Can refer to various kernel objects (not just files)– Can be passed to a standard set of functions:

• read, write, close, lseek, (and more)

– Can be inherited when a process forks a childCS 3214 Fall 2010

Examples

• 0-2 are initially assigned– 0 – stdin– 1 – stdout– 2 – stderr– But this assignment is not fixed – process can

change it via syscalls• int fd = open(“file”, O_RDONLY);• int fd = creat(“file”, 0600);

CS 3214 Fall 2010

Implementing I/O Redirection

• dup and dup2() system call• pipes: pipe(2)

CS 3214 Fall 2010

dup2

CS 3214 Fall 2010

#include <stdio.h>#include <stdlib.h>

// redirect stdout to a fileintmain(int ac, char *av[]){ int c;

int fd = creat(av[1], 0600); if (fd == -1) perror("creat"), exit(-1);

if (dup2(fd, 1) == -1) perror("dup2"), exit(-1);

while ((c = fgetc(stdin)) != EOF) fputc(c, stdout);}

The Big Picture

CS 3214 Fall 2010

Process 1

0

1

2

user view kernel view

Terminal Deviceopen(“x”)3

Open File

FileDescriptor x

open(“x”)

4

FileDescriptor

close(4)

dup2(3,0)

Process 2

0

1

2

3

Reference Counting

• Multiple file descriptors may refer to same open file– Within the same process:

• fd = open(“file”); fd2 = dup(fd);

– Across anchestor processes:• fd = open(“file”); fork();

• But can also open a file multiple times:– fd = open(“file”); fd2 = open(“file”);– In this case, fd and fd2 have different read/write offsets

• In both cases, closing fd does not affect fd2• Reference Counting at 2 Levels:

– Kernel keeps track of how many processes refer to a file descriptor –fork() and dup() may add refs

– And keeps track of how many file descriptors refer to open file• close(fd) removes reference in current process

CS 3214 Fall 2010

Practical Implications

• Number of simultaneously open file descriptors per process is limited– 1024 on current Linux, for instance

• Must make sure fd’s are closed– Else ‘open()’ may fail

• Number space is reused– “double-close” error may inadvertently close a

new file descriptor assigned the same number

CS 3214 Fall 2010

IPC via “pipes”

• A bounded buffer providing a stream of bytes flowing through• Properties

– Writer() can put data in pipe as long as there is space• If pipe() is full, writer blocks until reader reads()

– Reader() drains pipe()• If pipe() is empty, readers blocks until writer writes

• Classic abstraction– Decouples reader & writer– Safe – no race conditions– Automatically controls relative progress – if writer produces data faster

than reader can read it, it blocks – and OS will likely make CPU time available to reader() to catch up. And vice versa.

CS 3214 Fall 2010

Fixed Capacity Buffer

write() read()

CS 3214 Fall 2010

int main(){ int pipe_ends[2]; if (pipe(pipe_ends) == -1) perror("pipe"), exit(-1);

int child = fork(); if (child == -1) perror("fork"), exit(-1);

if (child == 0) { char msg[] = { "Hi" };

close(pipe_ends[0]); write(pipe_ends[1], msg, sizeof msg);

} else { char bread, pipe_buf[128];

close(pipe_ends[1]);

printf("Child said "); fflush(stdout); while ((bread = read(pipe_ends[0], pipe_buf, sizeof pipe_buf)) > 0) write(1, pipe_buf, bread); }}

pipe

Note: there is no race condition inthis code. No matter what the scheduling order is, the message sentby the child will reach the parent.

esh – extensible shell

• Open-ended assignment• Encourage collaborative learning

– Run each other’s plug-ins• Does not mean collaboration on your

implementation• Secondary goals:

– Exposure to yacc/lex and exposure to OO-style programming in C

CS 3214 Fall 2010

Using the list implementation

• Key features: “list cell” – here call ‘list_elem’ is embedded in each object being kept in list– Means you need 1 list_elem per list you want to keep an object in

CS 3214 Fall 2010

struct esh_pipeline:

…. struct list commands

struct list_elem head

struct list_elem tail

struct list_elem *next;struct list_elem *prev;

struct list_elem *next;struct list_elem *prev;

struct esh_command:

…. struct list_elem elem;

….

struct list_elem *next;struct list_elem *prev;

struct esh_command:

…. struct list_elem elem;

….

struct list_elem *next;struct list_elem *prev;

list_entry(e, struct esh_command, elem)