cs 3214 computer systems godmar back lecture 13. announcements project 3 milestone due oct 8 have...
Post on 29-Dec-2015
214 Views
Preview:
TRANSCRIPT
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)
top related