CS 5523 Operating Systems: Midterm II - reivew Instructor: Dr. Tongping Liu Department Computer Science The University of Texas at San Antonio

Transcription

1 CS 5523 Operating Systems: Midterm II - reivew Instructor: Dr. Tongping Liu Department Computer Science The University of Texas at San Antonio Fall

2 Outline Inter-Process Communication (20) Threads (50) Synchronizations (30) 2

3 Inter-Process Communication (IPC) Processes within a system may be independent or cooperating! Cooperating process can affect or be affected by other processes" Reasons for cooperating processes:" Ø Information sharing, e.g., sharing a file" Ø Computation speedup, e.g., subtasks for parallelism" Ø Modularity & Convenience ( e.g., editing, printing in the same time)" Cooperating processes need inter-process communication (IPC)" Ø Shared memory" Ø Pipe and Named Pipe" Ø Message passing" "

4 Shared Memory, Pros and Cons Pros Ø Fast bidirectional communication among any number of processes Ø Saves Resources Cons Ø Needs concurrency control (leads to data inconsistencies like Lost update ) Ø Lack of data protection from Operating System (OS)

5 Ordinary Pipes Ordinary Pipes allow communication in standard producer-consumer style Producer writes to one end (the write-end of the pipe) Consumer reads from the other end (the read-end of the pipe) Ordinary pipes are therefore unidirectional Require parent-child/sibling relationship between communicating processes

6 Named Pipes (FIFO) Named Pipes are more powerful than ordinary pipes " Communication is bidirectional " No parent-child/sibling relationship is necessary between the communicating processes " Several processes can use the named pipe for communication " Provided on both UNIX and Windows systems"

7 Lecture03: Thread and Implementation Motivation and thread basics Ø Resources requirements: thread vs. process Thread implementations Ø User threads: e.g., Pthreads and Java threads Ø Kernel threads: e.g., Linux tasks Ø Map user- and kernel-level threads Ø Lightweight process and scheduler activation Other issues with threads: process creation and signals etc. Threaded programs Ø Thread pool Ø Performance vs. number of threads vs. CPUs and I/Os CS5523: Operating UTSA 7

8 Thread vs. Process Responsiveness Ø Part of blocked Resource Sharing Ø Memory, open files, etc. Economy Ø Creation and switches Scalability Ø Increase parallelism Department of Computer UTSA 8

9 Process with Two Threads Thread 1 SP Program context: Data registers Condi.on codes Stack pointer (SP) Program counter (PC) stack brk PC Code, data, and kernel context shared libraries run-.me heap read/write data read-only code/data SP Thread 2 Program context: Data registers Condi.on codes Stack pointer (SP) Program counter (PC) stack 0 Kernel context: VM structures Descriptor table brk pointer

10 Threads vs. Processes Threads and processes: similarities Ø Each has its own logical control flow Ø Each can run concurrently with others Ø Each is context switched (scheduled) by the kernel Threads and processes: differences Ø Threads share code and data, processes (typically) do not Ø Threads are less expensive than processes ü Process control (creation and exit) is more expensive as thread control ü Context switches: processes are more expensive than for threads Ø Signal handler: shared or separate

11 Pros and Cons of Thread-Based Designs + Easy to share data structures between threads Ø e.g., logging information, file cache + Threads are more efficient than processes Unintentional sharing can introduce subtle and hard-toreproduce errors!

12 Multithreading Models: Pros and Cons Many-to-one One-to-one Many-to-many

13 Pthreads: POSIX Thread POSIX Ø Portable Operating System Interface [for Unix] Ø Standardized programming interface Pthreads Ø Thread implementations adhering to POSIX standard Ø API specifies behavior of the thread library: defined as a set of C types and procedure calls Ø Common in UNIX OS (Solaris, Linux, Mac OS X) Support for thread creation and synchronization Department of Computer UTSA 13

14 Linux Threads Linux uses the term task (rather than process or thread) when referring to a flow of control Linux provides clone() system call to create threads Ø A set of flags, passed as arguments to the clone() system call determine how much sharing is involved (e.g. open files, memory space, etc.) Linux: 1-to-1 thread mapping Ø NPTL (Native POSIX Thread Library) Department of Computer UTSA 14

15 Threads Memory Model Conceptual model: Ø Multiple threads run in the same context of a process Ø Each thread has its own separate thread context ü Thread ID, stack, stack pointer, PC, and GP registers Ø All threads share the remaining process context ü Code, data, heap, and shared library segments ü Open files and installed handlers Operationally, this model is not strictly enforced: Ø Register values are truly separate and protected, but Ø Any thread can read and write the stack of any other thread

16 Mapping Variable Instances to Memory Global var: 1 instance (ptr [data]) char **ptr; /* global */ int main() { int i; pthread_t tid; char *msgs[2] = { "Hello from foo", "Hello from bar" }; ptr = msgs; } for (i = 0; i < 2; i++) Pthread_create(&tid, NULL, thread, (void *)i);. Local vars: 1 instance (i.m, msgs.m) Local var: 2 instances ( myid.p0 [peer thread 0 s stack], myid.p1 [peer thread 1 s stack] ) /* thread routine */ void *thread(void *vargp) { int myid = (int)vargp; static int cnt = 0; } sharing.c! printf("[%d]: %s (svar=%d)\n", myid, ptr[myid], ++cnt); Local sta8c var: 1 instance (cnt [data])

17 Thread Pool Pool of threads Ø Threads in a pool where they wait for work Advantages: Ø Usually slightly faster to service a request with an existing thread than create a new thread Ø Allows the number of threads in the application(s) to be bound to the size of the pool Adjust thread number in pool Ø According to usage pattern and system load Department of Computer UTSA 17

18 Performance of Threaded Programs Suppose that the processing of each request Ø Takes X seconds for computation; and Ø Takes Y seconds for reading data from I/O disk For single-thread program/process Ø A single CPU & single disk system Ø What is the maximum throughput (i.e., the number of requests can be processed per second)? Example: suppose that each request takes 2ms for computation 8ms to read data from disk 1000/10ms = 100 Department of Computer UTSA 18

19 Lecture04: Concurrency and Synchronization Problems with concurrent access to shared data Ø Race condition and critical section Ø General structure for enforce critical section Synchronization mechanism Ø Hardware supported instructions: e.g., TestAndSet Ø Software solution: e.g., semaphore Classical Synchronization Problems High-level synchronization structure: Monitor Case study for synchronization Ø Pthread library: mutex and conditional variables Ø Java inherit monitor and conditional variable CS5523: Operating UTSA 19

20 Race Conditions Multiple processes/threads write/read shared data and the outcome depends on the particular order to access shared data are called race conditions Ø A serious problem for concurrent system using shared variables! How do we solve the problem?! Need to make sure that some high-level code sections are executed atomically Ø Atomic operation means that it completes in its entirety without worrying about interruption by any other potentially conflictcausing process Department of Computer UTSA 20

21 Critical-Section (CS) Problem Multiple processes/threads compete to use some shared data critical section (critical region): a piece of code that accesses a shared resource (data structure or device) that must not be concurrently accessed by more than one thread of execution. Problem ensure that only one process/thread is allowed to execute in its critical section (for the same shared data) at any time. The execution of critical sections must be mutually exclusive in time. Department of Computer UTSA 21

22 Solving the Critical-Section Problem Mutual Exclusion Ø No two processes can simultaneously enter into the critical section. Bounded Waiting Ø No process should wait forever to enter a critical section. Progress Ø Non-related process can not block a process trying to enter one critical section Relative Speed Ø No assumption can be made about the relative speed of different processes (though all processes have a non-zero speed). Department of Computer UTSA 22

23 General Structure for Critical Sections do { entry section critical section exit section remainder statements } while (1); In the entry section, the process requests permission. Department of Computer UTSA 23

24 Solutions for CS Problem Software based" Ø Peterson s solution" Ø Semaphores" Ø Monitors" Hardware based " Ø Locks" Ø disable interrupts" Ø Atomic instructions: TestAndSet and Swap Department of Computer UTSA 24

25 Hardware Instruction TestAndSet The TestAndSet instruction tests and modifies the content of a word atomically (non-interruptable)" Keep setting the lock to 1 and return old value. bool TestAndSet(bool *target){ boolean m = *target; *target = true; return m; } What s the problem? 1. Busy-waiting, waste cpu 2. Hardware dependent, not bounded-waiting do { Department of Computer UTSA while(testandset(&lock)); critical section //free the lock lock = false; remainder section } while(true); 25

26 Another Hardware Instruction: Swap Swap contents of two memory words void Swap (bool *a, bool *b){ bool temp = *a; *a = *b; *b = temp: } What s the problem? 1. Busy-waiting, waste cpu 2. Hardware dependent, not bounded-waiting bool lock = FALSE; While(true){ bool key = TRUE; LOCK == FALSE while(key == TRUE) { Swap(&key, &lock) ; } critical section; lock = FALSE; //release permission } Department of Computer UTSA 26

27 Semaphores Synchronization without busy waiting Ø Motivation: Avoid busy waiting by blocking a process execution until some condition is satisfied Semaphore S integer variable Two indivisible (atomic) operations: how? à later Ø wait(s) (also called P(s) or down(s) or acquire()); Ø signal(s) (also called V(s) or up(s) or release()) Ø User-visible operations on a semaphore Ø Easy to generalize, and less complicated for application programmers" Department of Computer UTSA 27

28 Semaphore Usage Counting semaphore integer value can range over an unrestricted domain" Ø Can be used to control access to a given resources with finite number of instances " Binary semaphore integer value can range only between 0 and 1; Also known as mutex locks! " S = number of resources while(1){ } mutex = 1 while(1){ } wait(s); use one of S resource signal(s); remainder section wait(mutex); Critical Section signal(mutex); remainder section

29 Monitors High-level synchronization construct (implement in different languages) that provided mutual exclusion within the monitor AND the ability to wait for a certain condition to become true monitor monitor-name{ shared variable declarations procedure body P1 ( ) {...} procedure body P2 ( ) {...} procedure body Pn ( ) {...} {initialization codes; } } Department of Computer UTSA 29

30 monitors vs. semaphores A Monitor: Ø An object designed to be accessed across threads Ø Member functions enforce mutual exclusion A Semaphore: Ø A low-level object Ø We can use semaphore to implement a monitor Department of Computer UTSA 30

31 Binary Semaphore and Mutex Lock? Binary Semaphore: Ø No ownership Mutex lock Ø Only the owner of a lock can release a lock. Ø Priority inversion safety: potentially promote a task Ø Deletion safety: a task owning a lock can t be deleted. 31