1. Recall that a process is a PROGRAM IN EXECUTION. 2. At any given time, the status of a process includes

Transcription

1 CPS221 Lecture: Processes and Threads last revised 8/13/10 Objectives 1. To introduce fundamental concepts concerning processes: state, pid, PCB 2. To introduce mechanisms for inter-process communication 3. To introduce threads Materials: 1. Diagram showing state of memory for a process 2. Diagram showing process states 3. Ability to demonstrate Unix commands on Mac and Linux 4. pipedoc.txt and pipedict.txt examples for pipeline demo + file with command to cut and paste plus shell script version 5. UnthreadedRacers and ThreadedRacers to demonstrate + code to project 6. AWThreadDemo.java to demonstrate 7. AWTBlockDemo.java 8. Handout of code for ThreadedRacers 9. UML Activity Diagram for Racer problem I. Processes A. As you know, abstraction is a fundamental design tool in many areas of computer science. In the realm of operating systems, we have already noted that the fundamental abstraction is the notion of a PROCESS. 1. Recall that a process is a PROGRAM IN EXECUTION. 2. At any given time, the status of a process includes a) A region of memory holding its code and data (1) The memory belonging to a process is typically divided into four regions (a) Code (called text in the Unix world) (b) Fixed data (static variables). (c) Heap: objects created dynamically as the program is running (e.g. by an operation such as new) (d) Stack - contains a frame for each routine currently executing that holds parameters, local variables and return addresses. PROJECT 1

2 State of memory when executing the following code at point shown int i = 3; a() { main() { int j = 7; Foo f = new Foo() f.a(3); } class Foo { double x; void a(int k) { int l;... } } i Frame for main() (exit at end) j f Frame for a() (return to main) k l (Room for growth) object of class Foo x (main(), a(), and any other code) STACK HEAP DATA CODE (2) The code and data regions are of fixed size, but the heap and stack can change size as the program runs. (a) The heap grows whenever an object is created by an operation such as new. Depending on the programming language in use, the space allocated for the object can be freed up for use by another object by explicit deletion or by garbage collection. But since it is not possible to predict when this might occur (if it ever does), such objects are said to have indefinite lifetime. (b) The stack grows when a routine is called, and shrinks when the routine returns. Routine call and return obeys a last-infirst-out order. (c) To allow the heap and stack to grow and shrink independently, they are allocated as two separate regions, growing in opposite directions as shown by the arrows. 2

3 b) The process s state - is it currently able to continue execution, or must further execution wait until some event occurs (e.g. the completion of an IO operation it has requested) Over the course of its lifetime, a process transitions between various states. PROJECT creation READY dispatch timer pre-emption IO or event complete exit RUNNING IO or event wait BLOCKED (1) On a one-cpu system, there is exactly one running process at any given time. (If there are no other processes eligible to run, the operating system includes a do-nothing null process that can be run until some other process becomes ready.) (2) (Discuss other transitions) (3) The diagram shows that a process terminates as a result of executing an exit() operation. Actually, many systems also allow a process to be forcibly terminated from the other states by some other process. c) The values of the various CPU registers - notably the program counter. (1) When a process is running on the CPU, these values actually reside in the CPU registers. (2) When some other process is running, these values are stored in operating system memory. 3

4 3. To facilitate references to the process, each process is given a unique process ID (pid) at the time it is created. Typically, this is an integer, which starts at 1 when the system is first started and increases continually as it is running, so that no two processes ever have the same pid. (If a 64-bit integer is used for the pid, then if one process is created every microsecond the set of possible pids will run out in about a million years!) 4. Though we use the term process, other terms have been and are still used for the same concept, including job and task (though each term is also sometimes used to mean something different.) B. To manage the various processes, the operating system maintains a set of data structures called PROCESS CONTROL BLOCKS (PCB's) - one per process. 1. Each PCB contains information about its process, including: a) Its pid b) The state of the process. c) The values of the CPU registers if the process is not currently running. (When the process is running, these values are actually in the hardware registers and change constantly) The set of values may include both values visible to the programmer and hidden registers such as those used for memory management. d) Scheduling, accounting, and resource allocation information. 2. One major use of the PCB's is in conjunction with a CONTEXT SWITCH operation. a) A context switch occurs whenever the a new process is given use of the CPU in place of the one that is currently running. b) During a context switch, the first thing that must happen is that the register values associated with the currently running process must be stored into its PCB, to be saved until the process next gets a chance to run. c) Then, the stored register values found in the PCB of the process about to run are copied into the CPU registers. 4

5 Example: Suppose we have a CPU with 5 registers: PC, SP, AC, page-table base, and page-table limit. (This is a very minimal set - real CPU s would have many more!) Suppose further that we have the following scenario: process 17 is currently running, and we wish to do a context switch to process 12. Something like the following would occur: BEFORE CPU Registers PCB 17 PCB 12 PC 1050 (Irrelevant) 6124 SP 2F AC Base Limit AFTER CPU Registers PCB 17 PCB 12 PC SP F AC Base Limit Note: As process 12 runs, the values in the CPU registers will change. Its PCB will not be updated to reflect these changes until the next context switch. d) Typical CPU s have several times as many registers as this example. In addition, because of the resultant invalidation of cache memory contents, a context switch turns out to involve significant overhead. 3. At any given time, each PCB is typically in one of several operating system queues. a) There is a ready queue (ready list) which holds the PCB s of all currently ready processes. b) There is a device queue associated with each shared device (such as a disk). It is not uncommon for a process to request an operation on such a device while it is busy servicing a request from some other process. In this case, the PCB for the requesting process is placed in a queue, waiting its turn to use the device. 5

6 c) A component of the operating system - called the scheduler - is responsible for managing these queues in order to make the most effective possible use of the resources. (We will discuss CPU scheduling later). C. One of the most important sets of services an operating system provides is those related to the management of processes - including: 1. Process creation. Most systems allow a process that is running to create a new process. a) The creator process is called the parent and the new process is called a child. (By repeated use of the create process service, a parent could create multiple children, of course.) b) Various aspects of the relationship between a parent and child are handled differently by different systems: (1) Memory image: (a) Unix: When a child process is created by the fork() system call, it shares its parent's text and inherits a copy of all its parents data (data, heap, and stack). The child typically acquires its own, separate text by using the exec() system call. (b) Windows: The CreateProcess() system call specifies - among other things - the name of the application that is to be run by the child. (2) Resources: Most systems impose some upper limits on how large a quantity of various system resources a process can claim (e.g. memory, open files etc.) On some systems, the resources used by a child are counted against its parents quota; on others each child has its own quota. (3) After new process creation, both the parent and child continue to execute in parallel. However, most systems provide a means by which the parent can wait until the child completes before proceeding further. (4) Possibility of the child living on after the parent terminates.: On many systems termination of a parent process automatically causes its children to terminate as well. 6

7 DEMO: ssh to Linux, ps -xl. Discuss the following COMMAND UID: PID: pid PPID: (pid of parent) STAT: S = waiting on an event (completion of child) R = ready or running (s = session leader, + = foreground process) 2. Process termination a) A process may terminate itself by invoking a suitable system service. b) On many systems, a parent process may also terminate one of its children through a system service call. c) Many systems provide a mechanism whereby a process belonging to a suitably-privileged user can terminate someone else s process as well. 3. Allocation of resources a) Maximum CPU time b) Maximum memory utilization c) Maximum number of open files d) Maximum number of child processes etc DEMO: limit command on Mac or in csh on Linux - go over. (Note: on Macs and Linux, maxproc is per user id - rest are per process) 7

8 II. Inter-Process Communication A. Multiprogrammed operating systems were first developed to allow multiple independent processes to share resources, but it soon became apparent that there were benefits to solving certain kinds of problems by the use of two or more cooperating processes working together on a common task. (An application of the principle of modularity that pervades computer science). B. One approach that arose in Unix is quite limited though often very useful - the use of something called a pipeline. Consider the following example: We want to spell-check a document that uses a non-standard vocabulary (e.g. perhaps it s in a language that our regular spell checker does not recognize.) We have available a dictionary file for our vocabulary; what we want to do is to identify words in our document that do not appear in our dictionary. For simplicity, assume that our document and dictionary are both ordinary text files. Also ssume that writing a special-purpose program does not seem like a good option. Here s an example (the language used is obbish! The dictionary has been made fairly minimal since this is only an illustration!) PROJECT pipedoc.txt, pipedict.txt 1. We could proceed as follows. a) Unix includes a transliterator utility called tr which performs transliteration. It is fairly easy to use this to take a text document and change the case of all letters to lowercase. DEMO: tr A-Z a-z < pipedoc.txt > tmp1.txt b) This same program can be used a second time to replace a sequence of characters other than those that can appear inside words with a single newline. If we apply this to the output produced by the first use of tr, we ge a file containing each word, all lowercase, on a separate line. DEMO tr -cs a-z '\012' < tmp1.txt > tmp2.txt c) Another utility called sort can sort a file into alphabetical order, with an option to squeeze out duplicates. DEMO: sort -u < tmp2.txt > tmp3.txt 8

9 d) Finally, the comm utility can be used to compare this file to the dictionary, reporting any lines that appear in the word list from the document but not in the dictionary (which are potentially misspellings). DEMO: comm -23 tmp3.txt pipedict.txt e) Of course, a couple of problems with this approach is it involves four distinct steps and litters the directory with three temporary files that should be deleted (but may not be!) 2. An alternative approach is the use of a Unix pipeline. The Unix shells allow the user to specify several commands separated by. Each command is run in a separate process, with the standard output of the first process connected to the standard input of the second, the standard output of the second connected to the third... DEMO: tr A-Z a-z < pipedoc.txt tr -cs a-z '\012' sort -u comm pipedict.txt 3. Actually, if this command were to be used frequently, it would be possible to turn it into an executable shell script by putting it in a file with file type.sh and making it executable. PROJECT, DEMO pipescript.sh C. Pipelines are only useful for the special case where we can string together existing programs to accomplish our task on a single system. Often, our task calls for special software and/or must be done using multiple systems. To illustrate this, consider an example I ve used in a previous course - a program that simulates a race between four racers. DEMO UnthreadedRacers 1. If implemented as a single sequential program, this is a bit messy. PROJECT UnthreadedRacers code - walk through the portion that runs the race 2. Implemented as four concurrent processes, however, the code is much cleaner and more modular PROJECT ThreaderRacers code - walk through run() method of innner class - note that main program no longer needs to keep track of positions or times for the individual racers. [We will discuss rest of code later.] 9

10 D. This, of course, raises the question of how two or more processes can share information in a general way. One approach is shared memory. 1. This was the strategy used in the Racer demo we just looked at - there was a single GUI frame shared by all four racers (with each having its own section of it). 2. In the standard multiprogramming model, each process has its own memory which is separate from that of all other processes. 3. Shared memory allows two processes to share some amount of memory in common (generally a subset of the memory allocated to each). a) One process (the owner of the memory) executes a system service that specifies that some region in its memory space is to be made available for sharing. b) The other process (or processes) then attach to this shared memory. 4. Operating systems that support shared memory (and not all do) may allow the owner process to make shared memory available for other processes to read but not write, or may allow both reading and writing by other processes. E. A second approach to inter-process communication is message passing. 1. The operating system supports two services - a send service that allows one process to send a message to another, and a receive service that allows a process to receive a message from another. a) The send service often completes immediately - the OS holds the message until it can be delivered. b) The receive service typically waits until a message arrives. c) From the operating system s standpoint, the message is just a series of bytes - the sending and receiving processes must put their own interpretation on it. 2. A message passing facility in the operating system is often used as the foundation for a strategy known as Remote Procedure Call. 10

11 a) We will briefly discuss an object-oriented version of this. In brief, a process is allowed to access methods of two different kinds of objects: (1) Local objects, residing in its own memory space. (2) Remote objects, residing in the memory space of another process, wh may the located on the same machine, or may be truly remote. b) There is a certain amount of overhead involved in setting up an RPC connection (which we will discuss later in the course). However, once this is done, the code needed to invoke a method of a remote object is essentially the same as the code needed to invoke a method of a local object. (1) When a method of a remote object is invoked, the RPC mechanism marshalls its parameters into a message, which is sent to the remote machine. Meanwhile, the process that invokes the message is placed into a waiting state until a reply message is received. (2) When the remote machine receives the message, it unmarshals the parameters, invokes the message, and then marshals the method s result into another message, which it sends back to the original machine. (If the method is void, a return message is still sent, but without any information.) (3) When the reply message arrives, the result is unmarshalled and returned to the calling process in just the way that it would have gotten a result back from a method on a local object. c) We will discuss RPC more thoroughly in the networks section of the course, since it is most often used when the processes involved are on different machines. 3. Once again, not all operating systems provide a message-passing facility - though most do (even those supporting shared memory as well). F. How do we compare these last two approaches to inter-process communication? ASK 11

12 III. Threads 1. Shared memory is much faster than message passing, because shared memory only involves operating system overhead for initial setup, while message passing involves operating system overhead for every operation. 2. However, shared memory is restricted to processes running on the same machine. Message passing is easily extended to support communication betweeen cooperating processes located at different physical locations - the message is simply sent over a network. 3. Shared memory also requires some mechanism for synchronizing the two processes - while this is inherent in message passing. 4. Finally, shared memory adds significant complexity to the memory management portion of the operating system. A. In modern operating systems, the notion of process has been broadened to include the notion of threads. 1. Some contexts speak of two kinds of processes - traditional, or heavy weight processes, and light weight processes - also known as threads. However, for clarity we will stick with using process for traditional heavy weight processes, and will call light weight processes. 2. In our discussion so far, each process has had a single thread of control, represented by its stack and set of register values. We now broaden this concept to allow for the possibility that a single process might have multiple threads of control. PROJECT: Figure Please note, too, that while we discussed interprocess communication between processes on different machines, multiple threads occurring within a single process are necessarily all on the same machine. B. The motivation for this developement is a desire to balance considerations of efficiency with considerations of software modularity. 1. We have already seen that the use of multiple processes running on the same machine entails periodic context switches, in which the CPU is passed from one process to another. On the other hand, a current trend in the design of complex software systems is to organize these systems as a set of cooperating processes, rather than as a single 12

13 monolithic process. The structuring of tasks as a collection of concurrent processes leads, of course, to increased frequency of context switching - which conflicts with our previously-stated goal of minimizing context switches for efficiency reasons. 2. It isn t always possible for cooperating processes to make use of shared memory, since this facility may not be included in the operating system and in any case involves a fair amount of complexity. On the other hand, the overhead of message passing can be considerable. C. When threading is used, a single process to be structured as a set of individual threads. 1. All the threads share the same code, data, and heap memory. There is no memory protection between threads in the same process - any thread may alter any data item. 2. Each thread has its own register context (including PC), and its own stack. (All the stacks for the various threads are located in the same data space; but each uses a different "chunk" of this space for its stack.) 3. Threads have two major advantages: a) A context switch between threads it the same process may be faster than a context switch between processes, since only register context needs to be saved and restored - not memory management context. Thus one can have the modularity advantages of separate processes with less overhead. b) Since all the threads share the same data, information sharing between the threads does not require the overhead of message passing. D. Threads can be implemented in two different ways: 1. By the use of library routines that run in user mode, independent of the operating system. (I.e. the operating system manages a single process; the process manages its own threads.) Another name for this is the many to one model - many threads in a single process map to a single thread as far as the kernel is concerned. 2. By adding a threads facility to the operating system. We now have distinct system services for: a) Creating a new process (initially consisting of a single thread). 13

14 b) Creating a new thread within an existing process. Another name for this is the one to one threading model - each thread in the process is know to the kernel. 3. The former approach is simpler, and minimizes the overhead involved in a context switch between threads (since no system call is involved). The latter, however, allows one thread in a process to block itself on an IO operation while allowing the other threads to continue executing. 4. Moreover, on a multicore system that supports threads in the operating system, it is typically possible for two or more threads in a single process to be running concurrently on separate cores. E. We will now consider the threading facilities of Java. 1. One important feature of Java is that it incorporates support for threads as part of the JVM and the standard library. Other new languages incorporate similar mechanisms, and much the same effect can be achieved in any language by using a threading library such as the pthreads facility in Unix-like systems or the Windows threading facilities. We will discuss the Java approach here, but the basic concepts are transferable to other models. 2. It is fairly easy to create Java programs that use multiple threads. a) In fact, you ve already done so without being aware of it, since even the simplest Java program uses multiple threads. (1) Every Java program has a main thread that executes the main() method of an application or the start() method of an applet. (2) Every Java program has one or more implementation-supplied background threads that handle various behind the scenes tasks - e.g. garbage collection. (3) Java programs that use the awt have one or more implementation-supplied threads that perform various awt tasks, as well. EXAMPLE: AWTThreadDemo.java (a) Run. Note how clicking buttons changes direction of counting. 14

15 (b) Examine code - show count() and actionperformed() methods. Note that two methods perform the major tasks: count() increments/decrements and displays the count value, and actionperformed responds to clicks on up and down by setting the increment value to +1 or -1 as the case may be. (c) How does execution switch from counting to modifying the increment when a button is clicked? These two methods are actually executed by two different threads: count() is executed by the main thread, and actionperformed() by the awt event thread. The awt event thread is a part of the Java implementation that waits for a gesture that would cause an event to occur, and then calls the handler for that event. (d) Comment out the time waster loop in the source code, recompile and run. Note that: i) It now counts much faster ii) Only a small fraction of the values computed are actually displayed. This is because another thread - the awt painting thread - is actually responsible for updating the display. It is triggered each time the label contents is changed - however, it takes long enough to redraw the label once that the count is bumped up/down many times during the same period. b) Threads in Java are orthogonal to objects: a given thread may access many objects, and a given object may have its methods performed by many threads. Objects Threads E.g. in the example just given: 15

16 (1) The main thread accesses the AWTThreadDemo object, the frame, and the various components that are part of it - including, in particular, the label that displays the count value. (2) The event thread accesses the AWTThreadDemo object. (3) The painting thread is given a task to do when the event thread modifies the text of the label that displays the count value, and then accesses the label to update its visual display on the screen. 3. While all Java programs make implicit use of threads, it is also possible to explicitly use threads in a Java program. Why would one want to do so? ASK a) Some applications lend themselves to using multiple threads - the logic of the application is cleaner this way. EXAMPLE: The Racer program we looked at earlier b) A server program may use a separate thread for servicing each client. This tends to produce cleaner, more modular code. c) A web browser that is downloading a large movie may start playing it before it is completely downloaded, finishing the download while earlier portions are playing. This is typically done by using two separate threads: a producer thread that carries out the download, and a consumer thread that plays the file. (Of course, the speeds must be such that the consumer doesn t catch up with the producer or the movie has to stop playing.) d) In a program that uses the awt (including Swing), any computation that is performed by an event handler is, in fact, done by the awt event thread. A consequence of this is that, while one awt event is being handled, no other awt events can be responded to. (1) For this reason, it is good practice to minimize the amount of computation done by event handlers or methods they call directly. (2) If handling an event requires a great deal of processing, or entails the risk of going into an infinite loop, it is better to delegate this to a separate thread. EXAMPLE: AWTBlockDemo.java 16

17 (a) DEMO - Note how it is unresponsive to stop button until count reaches 100 (b) SHOW CODE - Note that the problem is that both count() and stop() are executed by the awt thread - therefore stop() cannot be executed while the thread is busy doing count() 4. While we have said that Java threads are conceptually orthogonal to objects, the java.lang package includes a class java.lang.thread, and an object of this class is needed for each thread in a given program. The Thread object serves as a mechanism for creating and accessing the thread. However, the thread itself is a flow of control, not an ordinary object - i.e. the thread is conceptually distinct from the Thread object that provides access to it. We will illustrate this by walking through the rest of the code from the threaded version of the Racer example HANDOUT Code for ThreadedRacer a) To create a new thread, one must first create an object of class java.lang.thread or a subclass. b) Then, the associated thread must be started. This is accomplished by activating the start() method of the Thread object. c) The code that is to be executed by the new thread must be specified in one of two ways. (1) Create a class that implements the Runnable interface (which requires a run() method), and pass an instance of this class to the constructor of class java.lang.thread. Create and start the new thread. The code that the new thread executes is the run() method of this Runnable object. EXAMPLE: Note in inner class Racer (a) Each racer object is a GUI component that has an index from which it can determine its color and it keeps track of a position (tbat goes from 0 to 100) - see instance variables on the bottom of page 2. (b) Each racer object can draw itself as a partially filled in boix on the screen. (See paint() method on page 2.) (c) Each racer object is added to the GUI when it is created. 17

18 (d) The main program also creates four threads (one for each racer) in the main program immediately following creation of the racers. Each thread is associated with a racer that is specified when it is created (parameter to constructor). Thus, each racer is actually represented by two objects: a Racer object and a Thread object. (See page 1 again) (e) Each thread is started by invoking its start() method, just after the threads are created. (f) Each thread executes the run() method of the racer object is is associated with (page 2). This run() method sleeps for a random amount of time, increments its position, and then redraws itself. The run() method exits when the position reaches 100, at which point the corresponding thread terminates (this happens automatically). Note how each object need only keep track of the position of one racer (g) While the racers are running, there are therefore actually five threads in operation - the four racer threads, plus the main thread that created them. (2) Java allows an alternate method for doing the same thing - one can subclass java.lang.thread by a subclass that has its own run() method.. This is somewhat simpler than creating a Runnable object and then using that to create a thread (half as many objects involved) - but can t be used in this case because Java does not allow multiple inheritance, so creating a subclass of java.lang.thread means that the object containing the run() method cannot subclass any other class. Creating a separate implementation of the Runnable interface allows the object containing the run() method to subclass some class as well (e.g. in this case JPanel) (However, we will use this simpler approach in the lab you will do on threads.) d) Java also provides an operation known as join() which allows one thread to wait for another to complete. When this happens, the first thread continues. (In effect, the two threads are joned into one). (1) This is used in the Racer program. The main thread executes the join() method of each thread in turn (bottom of page 1). This method causes the main thread to wait until the racer thread has completed - at which point the two are joined into one thread. 18

19 (2) Because the main thread waits, in turn, for each racer, it does not get out of the loop until all four racers have terminated, at which point it prints the message "All racers are done". e) Actually, the Java language recognizes two distinct categories of threads: (1) User threads execute user code. (E.g. the main program is executed by a user thread, and threads that it creates are typically user threads.) The five threads in our racer example are all user threads. (2) Daemon threads typically execute system code. (E.g. the garbage collection thread etc. are daemon threads.) (3) The basic distinction is this: when all the user threads for a given program have terminated, the program itself terminates. Daemon threads can still be in existence; they are terminated when the last user thread terminates. (4) Note that the awt threads are actually set up as user threads. This is because it is quite common for the main program of a GUI application to simply set up the GUI and then terminate. If the awt thread(s) were daemon threads, the program would terminate at that point, before the user could do anything! F. As a final note, recall that UML provides a nice mechanism for depicting multithreaded programs: the Activity Diagram. 1. EXAMPLE: HANDOUT: Activity Diagram for Racer Problem 2. Rounded rectangles represent activities. 3. Arrows represent flow from one activity to the next. Each activity is assumed to start as soon as its predecessor completes. 4. Where there is concurrency, the diagram shows forking of one thread into two or more, and joining of two or more threads into one. (Forks and joins should match.) 5. The diagram uses swim lanes to show the various parts of the system that are performing a task concurrently. 19