CS 5523: Operating Systems

Transcription

1 CS 5523: Operating Systems Instructor: Dr. Tongping Liu Midterm Exam: Oct 6, 2015, Tuesday 7:15pm 8:30pm CS5523: Operating UTSA 1

2 Lecture1: OS Overview Operating System: what is it?! Evolution of Computer Systems and OS Concepts Different types/variations of Systems/OS Ø Parallel/distributed/real-time/embedded OS etc. OS as a resource manager Ø How does OS provide service? interrupt/system calls OS Structures and basic components Ø Process/memory/IO device managers Basic design approaches Ø Monolithic/layered/microkernel/virtual machine etc. CS5523: Operating UTSA 2

3 Components in Operating System Process/thread Management Ø CPU (processors): most precious resource Memory Management Ø Main memory File Management à data /program Secondary-Storage Management à disk I/O System Management à I/O devices Protection and Security à access management I/O devices 3

4 OS Interface: APIs and System Calls For application programmers Application programming interface (API) Ø The run-time support system (run-time libraries) provides a system-call interface, that intercepts function calls in the API and invokes the necessary system call within the operating system System calls provide the interface between a running program and the operating system. Ø Generally available in routines written in C and C++ Ø Certain low-level tasks may have to be written using assembly language 4

5 Example: System-Call Processing 5

6 . Types of System Calls Process control" File management" Device management" Information maintenance" Communications" Protection" "

7 System call control flow - Linux User applica+on calls a user- level library rou+ne (gettimeofday(), read(), exec(), etc.) Invokes system call through stub, which specifies the system call number. From unistd.h: #define NR_getpid 172 SYSCALL( NR_getpid, sys_getpid) This generally causes an interrupt, trapping to kernel Kernel looks up system call number in syscall table, calls appropriate func+on Func+on executes and returns to interrupt handler, which returns the result to the userspace process 7 4/5/2012

8 Interrupt Mechanisms Save the current process state Interrupt transfers control to the interrupt service routine (ISR) generally through interrupt vector containing the addresses of all the service routines. ISR: Separate segments of code determine what action should be taken for each type of interrupt. Once the interrupt has been serviced by the ISR, the control is returned to the interrupted program. 8

9 Basic Interrupt Processing 1. The interrupt is issued 2. Processor finishes execution of current instruction 3. Processor signals acknowledgement of interrupt 4. Processor pushes PSW(Program Status Word) and PC to control stack 5. Processor loads new PC value through the interrupt vector 6. ISR saves remainder of the process state information 7. ISR executes 8. ISR restores process state information 9. Old PSW and PC values are restored from the control stack 9

10 Lecture2: Process Management Basic concepts of process Ø Process control block (PCB) and address space Basic operations for process management Ø Process creation/termination States of process: different queues Ø ready, running, or wait etc Ø Context switch: multiple hardware running contexts Scheduling of process: CPU scheduling Ø Basic scheduling algorithms: FIFO, SJF etc Inter process communication Ø shared memory and message CS5523: Operating UTSA 10

11 Process vs. Program Program: a set of functions Ø a passive entity Ø stored as files on disk Process: a program in execution Ø Dynamic concept: running of a program How do we run a program? What are steps to create a process? 11

12 Process: Running Context Registers: in addition to general registers Ø Program Counter (PC): contains the memory address of the next instruction to be executed. Ø Stack Pointer (SP): points to the top of the current stack in memory. The stack contains one frame for each procedure that has been entered but not yet exited. Ø Program Status Word (PSW): is an IBM System/360 architecture and successors control register, which performs the function of a Status register and Program counter in other architectures Higher level resources: open files etc. Synchronization and communication resource: semaphores and sockets 12

13 Example: PCB in Linux (task_struct) Process Management Registers Program Counter Stack Pointers Process State Priority Scheduling Parameters (slice) Process ID Parent process Process group Time when process started CPU time used Memory Management Pointer to text (code) segment Pointer to data segment Pointer to stack segment File Management Root directory Working directory User Id Group Id List of open files 13

14 Context Switch When CPU switches to another process, the system must save the state of the old process and load the saved state for the new process via a context switch! Context of a process represented in the PCB" Context-switch time is overhead" Ø 1 ~ 1000 ms" Hardware support" Ø Multiple set of registers" Other performance issues/problems" Ø Cache content: locality is lost" Ø TLB content: may need to flush"

15 Process Creation Address space" Ø Child duplicate its parent (data, program)" Ø Child has a program loaded into it (exec())" Execution" Ø Parent and children execute concurrently" Ø Parent waits until children terminate" Resource sharing: complicated" Ø Shared open files, but not descriptors" Ø Different page tables"

16 An Example: Unix fork( ) pid = 25 Data Text Stack Process Status File File Resources Resources pid = 26 Data Text Stack Process Status < > int cpid = fork( ); if (cpid = = 0) { <child code> exit(0); } <parent code> wait(cpid); cpid = 26 < > int cpid = fork( ); if (cpid = = 0) { <child code> exit(0); } <parent code> wait(cpid); cpid = 0 UNIX kernel 16

17 Create & Terminate Processes What does this print out? void main() { printf("l0\n"); if (fork()!= 0) { printf("l1\n"); if (fork()!= 0) { printf("l2\n"); fork(); } } printf("bye\n"); } L0 L1 L2 Bye Bye Bye Bye 05_fork.c

18 Activities in Processes Bursts of CPU usage alternate with periods of I/O wait CPU-bound: high CPU utilization, interrupts are processed slowly I/O-bound: more time is spending on requesting data than processing it Process 1: CPU bound" Total CPU usage" CPU bursts" I/O waits" Process 2:" I/O bound" Time" Total CPU usage" 18

19 Multiprogramming CPU-I/O Burst Cycle Multiprogramming is a form of parallel processing in which several programs are run at the same time on a uniprocessor. Ø Objective? Maximize CPU utilization. When a process wait for IO, all waiting time is wasted and no useful work is accomplished. 19

20 Classical Scheduling Algorithms FCFS: non-preemptive, based on arrival time Ø Long waiting time, e.g. long process before SSH console? SJF(shortest job first): preemptive & non-preemptive Ø Optimal in term of waiting time RR (Round-robin): preemptive Ø Processes take turns with fixed time quantum e.g., 10ms Priority-based scheduling Ø Real-time systems: earliest deadline first (EDF) Multi-level queue (priority classes) Ø System processes >faculty processes >student processes Multi-level feedback queues: short à long quantum 20

21 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" "

22 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)

23 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

24 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"

25 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 25

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

27 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

28 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!

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

30 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 30

31 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 31

32 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

33 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 sta-c var: 1 instance (cnt [data])

34 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 34

35 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 35

36 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 36

37 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 37

38 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 38

39 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 39

40 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 40

41 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 41

42 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 42

43 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

44 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 44

45 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 45

46 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. 46

47 Types of questions on Midterm1 Question answering: Ø Example: What is a system call? Problem Analysis: Ø Example: drawing the Gantt chart for FIFO CS5523: Operating UTSA 47