COE518 Lecture Notes Week 4 (Sept. 26, 2011)

Transcription

1 coe518 (Operating Systems) Lecture Notes: Week 4 Page 1 of 11 COE518 Lecture Notes Week 4 (Sept. 26, 2011) Topics Why fork(), then exec()? The delta list structure Alternative approach to Lab 2 More on processes More or threads Amdahl's Law Textbook sections Stallings (7 th edition): Chapter 4.3 (Multicore and multithreading) Tanenbaum (3 rd edition): Chapters 2.1 (Processes), 2.2 (Threads), 4.3 (Multicore and multithreading) Announcements Quiz: Wednesday October 12, 2011 Midterm: Wednesday October 26, 2011 Why fork() then exec()? Forking has been described as creating an exact clone of a process (that invoked the fork()) by copying all its program and data areas into newly allocated ones for the newly created child process. Typically, the child process then almost immediately overlays all of these memory areas with

2 coe518 (Operating Systems) Lecture Notes: Week 4 Page 2 of 11 new content for a totally different process that is exec'ed. This seems ridiculous! Some clarification: The copying is more conceptual than real. For example, the program area is usually read-only and can be safely shared amongst different processes. Similarly, the data area is usually small and the child often only needs read-access to it. (Memory management hardware can be used to permit safe read-only access to the child process. If the child does perform a write, the hardware would detect this and the OS would then make a physical copy of part or all of the memory segment for the child. The child does need its own stack but is unlikely to need write access far down. So while the copying of data is conceptually accurate, the actual overhead is quite small. And the advantages of the child having access to its parent's knowledge are considerable. This is particularly clear when writing a shell program. The code below illustrates how output redirection is parsed by the shell and then implemented by the child. Some things to know when examining the code: The OS maintains an array of file descriptos for each process. Element zero is stdin, fd[1] is stdout and fd[2] is stderr. Redirecting stdout to a file rather than the default terminal is done with dup2(somefd,1) #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/wait.h> #include <sys/types.h> #include <sys/stat.h> #include <string.h> int main(int argc, char * argv[], char **envp) { pid_t child; char * myargv[] = {NULL, NULL, NULL, NULL; char * stdout_redirect = "";//Default:stdout not redirected int status; /* Hard coded demo code: Assumes user typed: * ls -l > junk

3 coe518 (Operating Systems) Lecture Notes: Week 4 Page 3 of 11 * Such would be parsed to set up myargv as * shown below. The ">" (redirection symbol) * would be parsed by the shell and the * word following it ("junk") * would be recognized as the file stdout should * be redirected to. The redirection * is then implemented by the child. */ myargv[0] = "ls"; myargv[1] = "-l"; stdout_redirect = "./junk"; /* End of demo code */ child = fork(); if (child == 0) { if (strcmp("", stdout_redirect)!= 0) { //child changes stdout file //by redefining fd[1]. int stdout_now = open("./junk", O_CREAT O_WRONLY O_TRUNC, 0666); dup2(stdout_now, 1); execvp(myargv[0], myargv); return EXIT_FAILURE; wait(&status); fprintf(stderr, "Parent of %d\n", child); return EXIT_SUCCESS; The Delta List A delta list is an efficient data structure for maintaining a list (of arbitrary length) of events scheduled for some future time. Tine flows disretely by ticks; one tick could be a millisecond, a second, a minute or whatever the application requires. The key of the first item on the list is the number of ticks remaining before the event is scheduled to occur. The first item on the list describes the event that will be first one to be triggered. The key for the second item is the number of ticks it should wait after the first item is triggered.

4 coe518 (Operating Systems) Lecture Notes: Week 4 Page 4 of 11 Similarly, the key for the third item is the number of ticks after the second item. At each tick, the key for the first item on the list is decremented. If it reaches zero, it is removed from the list and the action indicated is triggered. If after removing it, the new head of the list has a key of zero, it is also removed and triggered. This continues until the head of the list has a non-zero key. Example: Suppose there are 3 future events. Event A is scheduled to be triggered in 2 ticks from now ; Event B in 3 ticks; and Event C in 7 ticks. The delta list would look something like: Key Event 2 A 1 B 4 C After one tick, we have: Key Event 1 A 1 B 4 C After two ticks, we have: Key Event 0 A 1 B 4 C Since the key is zero, Event A is deleted and triggered. Key Event 1 B

5 coe518 (Operating Systems) Lecture Notes: Week 4 Page 5 of 11 4 C After 3 ticks, Event B's key is zero and it is deleted and triggered. Key Event 4 C After 4 more ticks (a total of 7), Event C is removed and triggered. New events can be inserted at any time. For example, suppose that after one tick with the previous example we want to insert a new Event D that should occur 3 ticks from now Key Event 1 A 1 B 1 D 3 C An alternative approach to Lab 2 The suggested approach to Lab 2 is: Collect the entire line into a buffer (an array of chars). Parse the buffer to identify each word; determine its length, use malloc(...) to allocate enough memory for it (string length + 1), copy the word to it and make myargv[i] (where i is 0 for the first word, 1 for the second, etc) point to the allocated memory. An advantage of this approach is that it is composed of several smallish steps and gives you experience with malloc(). There is an alternative approach which is somewhat more elegant and more efficient; the disadtage is that it is all one step and yuo have to get it all right. The alternative approach is:

6 coe518 (Operating Systems) Lecture Notes: Week 4 Page 6 of 11 Set myargv[0] to the first non-white character you get from stdin and place in the buffer. Continue reading character by charcter, copying into the buffer until you hit whitespace. Then place '\0' in the buffer until you encounter a non-whitespace character. That is the start of the myargv[1] pointer. Continue till you get the end of line character. More about processes A process consists of: 1. A program area in memory containing the machine language instructions of the process. 2. A data area in memory which can be separated into 3 components: i. Space for the runtime stack. ii. Space for global variables. iii. Space for a heap for dynamically allocated memory. (The size of the heap can also be increased with an OS call.) 3. A Process Control Block (PCB) which contains: i. Process state: Running, Ready (ready to run), or Blocked (waiting for something). When a process is blocked, it cannot continue running until some event occurs. For example, it could be waiting for I/O, for some time to elapse (usleep()), for some interprocess communication (IPC), for its child to die (wait()), etc. ii. Process ID Number (PID): A unique identifier for the process. iii. Owner (or User): On a multi-user system, the user who initiated the process. (When a user logs off, all processes owned by him or her are usually terminated.)q iv. CPU state: The values of all CPU registers the last time the process was running (or the initial values if the process has not yet run.) v. Memory areas: Description (starting address and size) of the memory segments used by the process. vi. Parent ID (PPID): PID of the parent process. vii. Statistics: How much time the CPU has been used (both user and supervisor modes). viii. Priority: Used by the scheduling algorithm to select a Ready process to run. May be modified dynamically by the OS. ix. Blocked information: Flags and messages indicating why the process is blocked. x. Resources: e.g. Open files

7 coe518 (Operating Systems) Lecture Notes: Week 4 Page 7 of 11 Processes should not interfere with one another. In particular, Process A should not be able to read or modify any memory location belonging to Process B. Modern processors usually have hardware and OS software that prevents this from happening no matter how buggy a process may be. Smaller processors (such as the 68hc12) do not have this capability. Multitasking OSes can still be used but all processes must be carefully tested to ensure that they do not access memory not belonging to them. Most processors (except those those for tiny embedded systems) offer the memory management hardware that the OS programs to ensure that processes do not interfere with each others memory. (Most processors go even further than this minimum requirement and allow virtual memory to be used.) There are also certain things that only the OS should be able to do. For example, if concurrent processes were both allowed to access the same physical printer, the printed result would be gibberish a mishmash of the two outputs. This means that the OS code (even at the machine language level) must be able to do things that ordinary user written code cannot do. For example, a user should not be allowed to run an assembly language program that disables interrupts while OS code should be allowed to disable interrupts. This requires that the CPU have at least 2 modes of operation: Kernel: all machine language instructions are allowable. User: Attempts to execute certain instructions (such as disable interrupts) result in an Illegal Instruction Exception. Processor capabilities OK, we need kernel and user modes. Question: But how does the CPU switch from one mode to another? Answer: Any interrupt (hardware or software) puts the CPU into kernel mode. Once the interrupt has been handled (and this may put the current process into the BLOCKED state in which case the scheduler will be invoked), the kernel will eventually return from the interrupt (the equivalent of the rti instruction on the 68hc12 although this CPU does not have separate kernel/user modes) and the previous mode will be restored. If the previous mode were user, that mode is resumed. Similarly, if the interrupt occurred during kernel mode, the rti instruction will maintain the CPU in kernel mode. Question: How does an application programmer get access to an I/O device (keyboard or window) or any other service that only the OS can do? Answer: Suppose the application programmer is writing in assembler (and high level languages

8 coe518 (Operating Systems) Lecture Notes: Week 4 Page 8 of 11 are ultimately translated to machine language). The programmer may want to output Hello world\n and would set up the parameters to the printf subroutine (which they did not write) and then code something like JumpToSubroutine _printf That subroutine will then ask the OS to perform the actual output. But jsr doesn't cut it since that does not change the CPU mode to kernel. Instead, a software interrupt (or trap ) instruction is executed to to request the OS service. The user program indicates the nature of the request and its parameters in specific machine registers. Once in kernel mode the OS code examines the request and, if it is legal performs it and eventually returns from interrupt which puts the CPU into its previous mode (user) and the user code continues. Note that when the CPU is in kernel mode, it is still executing on behalf of the same process. The CPU utilization statistics (maintained in the Process Control Block) keep track of the time spent in each mode. This can be demonstrated by timing the execution of the following two silly programs. /* Compute a lot: mainly user mode */ #include <stdlib.h> main() { int i; for(i = 0; i < ; i++); exit(0); /* Do a lot of output (to /dev/null!!): more kernel mode */ #include <stdlib.h> #include <unistd.h> #include <stdio.h> main() { int i; for(i = 0; i < ; i++) { // putchar('a'); // fflush(stdout); write(1, "abc", 1); //OS call to output 1 char exit(0); Following is the output of the time command using the cygwin bash shell under Windows 7 on an AMD dual-core C-50 processor. $ time./outalot.exe > /dev/null real 0m15.307s

9 coe518 (Operating Systems) Lecture Notes: Week 4 Page 9 of 11 user sys 0m8.735s 0m5.849s $ time./computealot.exe real user sys 0m10.178s 0m9.344s 0m0.139s More about threads Threads are similar to processes: only one threat at a time can execute on a CPU. One process can contain multiple threads. Unlike processes (which have independent unshared resources such as memory and files), threads within a process share all of the processes resources. Because another set of resources do not have to be enabled when switching from one thread to another (in the same process), the context switching is much faster for a thread than for a process. Note: processes are sometimes call Heavyweight Processes and threads Lightweight Processes. Programmers writing single-threaded applications rarely have to be concerned about interprocess communication and resource sharing problems. (The OS takes care of most of these details.) But application programmers writing multithreaded apps do need to be concerned about these things to avoid problems like deadlock and starvation (topics we will examine shortly). For example, virtually all Graphical User Interface programs are multithreaded (one thread to interact with the user and other threads to do the actual computation.) Fortunately, modern GUI frameworks hide these nasty details from the programmer with library classes that take care of the details. However, explicit multithreading is increasingly popular due to the explosive growth in multicore processors. (i.e. A single threaded process cannot take advantage of the other cores.) Amdahl's Law Gene Amdahl showed the following potential speedup factor for a multitasking program where there are N processors and a fraction, f, of the code that is necessarily sequential (cannot be parallelized).

10 coe518 (Operating Systems) Lecture Notes: Week 4 Page 10 of 11 Speedup= 1 f + (1 f ) N Questions 1. An initially empty Delta List is initialized at time 0 so that the following events will be triggered at the indicated times: Event time 20; Event B@ time 40; Event time 30; a. Show what the list looks like following this initialization. b. Show what the list looks like 15 ticks later. c. One tick later (16 ticks from the beginning) two events are added: Event D to be triggered 10 ticks later and Event E to be triggered 50 ticks later. Show the resulting Delta List. 2. A browser can implement tabs using separate processes or separate threads for each tab. Give one advantage and one disadvantage of using processes rather than threads. 3. Consider searching through a collection of items to see if a particular item exists. a. What fraction of the code is necessarily sequential? b. If finding the answer takes 10 seconds with one processor, how long will it take with 100 cores? 4. Suppose we have a CPU with 2 modes of operation: user and kernel. The OS has a subroutine called lauch\nuclearmisslesanddestroytheplanet. Why is it impossible for an ordinary application programmer to kill us all? Answers 1. a. A:20 -> C:10 -> B:10->null b. A:5 -> C:10 -> B:10 -> null

11 coe518 (Operating Systems) Lecture Notes: Week 4 Page 11 of 11 c. A:4 -> D:6 -> C:4 -> B:10 -> E:10 2. Advantage: A bug in one tab cannot crash other tabs. Disadvantage: Slower. 3. There is no essential sequential code. (Each of N processors can search 1/N of the search space.) So 100 processors can perform the task in 0.1 seconds. 4. If a program in user mode attempted jsr lauchnuclearmisslesanddestroytheplanet the OS (and memory management hardware) would recognize that the attempt to access a subroutine in kernal space was illegal. Even if the user knew the special software interrupt instruction and parameters needed to access this kernel subroutine,the kernel OS code could then verify that the user had permission to use this subroutine and deny access if they were not authorized to do so. (Your professor thinks that a well-written OS should deny access to anyone trying to execute such code.)