CMPE 135: Object-Oriented Analysis and Design April 30 Class Meeting

Slides:



Advertisements
Similar presentations
Operating Systems Semaphores II
Advertisements

1 Interprocess Communication 1. Ways of passing information 2. Guarded critical activities (e.g. updating shared data) 3. Proper sequencing in case of.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Chapter 2 Processes and Threads
Chapter 6: Process Synchronization
EEE 435 Principles of Operating Systems Interprocess Communication Pt II (Modern Operating Systems 2.3)
CY2003 Computer Systems Lecture 05 Semaphores - Theory.
Avishai Wool lecture Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication.
Concurrent Processes Lecture 5. Introduction Modern operating systems can handle more than one process at a time System scheduler manages processes and.
Synchronization Principles. Race Conditions Race Conditions: An Example spooler directory out in 4 7 somefile.txt list.c scores.txt Process.
Concurrency: Mutual Exclusion, Synchronization, Deadlock, and Starvation in Representative Operating Systems.
Chapter 2.3 : Interprocess Communication
1 Outline Processes Threads Inter-process communication (IPC) Classical IPC problems Scheduling.
1 Interprocess Communication Race Conditions Two processes want to access shared memory at same time.
Concurrency 1 CS502 Spring 2006 Thought experiment static int y = 0; int main(int argc, char **argv) { extern int y; y = y + 1; return 0; }
1 Race Conditions/Mutual Exclusion Segment of code of a process where a shared resource is accessed (changing global variables, writing files etc) is called.
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
Pthread (continue) General pthread program structure –Encapsulate parallel parts (can be almost the whole program) in functions. –Use function arguments.
CS 149: Operating Systems February 17 Class Meeting Department of Computer Science San Jose State University Spring 2015 Instructor: Ron Mak
The University of Adelaide, School of Computer Science
MODERN OPERATING SYSTEMS Third Edition ANDREW S. TANENBAUM Chapter 2 Processes and Threads Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall,
CS 152: Programming Language Paradigms May 7 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Classical problems.
Chapter 7 -1 CHAPTER 7 PROCESS SYNCHRONIZATION CGS Operating System Concepts UCF, Spring 2004.
Chapter 6 – Process Synchronisation (Pgs 225 – 267)
CS 151: Object-Oriented Design November 21 Class Meeting Department of Computer Science San Jose State University Fall 2013 Instructor: Ron Mak
1 Pthread Programming CIS450 Winter 2003 Professor Jinhua Guo.
1 CMSC421: Principles of Operating Systems Nilanjan Banerjee Principles of Operating Systems Acknowledgments: Some of the slides are adapted from Prof.
CS252: Systems Programming Ninghui Li Based on Slides by Prof. Gustavo Rodriguez-Rivera Topic 11: Thread-safe Data Structures, Semaphores.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
1 Condition Variables CS 241 Prof. Brighten Godfrey March 16, 2012 University of Illinois.
CS 152: Programming Language Paradigms April 30 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak.
CS 151: Object-Oriented Design November 26 Class Meeting Department of Computer Science San Jose State University Fall 2013 Instructor: Ron Mak
Semaphores Reference –text: Tanenbaum ch
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
Web Server Architecture Client Main Thread for(j=0;j
Case Study: Pthread Synchronization Dr. Yingwu Zhu.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Interprocess Communication Race Conditions
Semaphores Reference text: Tanenbaum ch
CS703 – Advanced Operating Systems
Background on the need for Synchronization
Multithreading Tutorial
Operating Systems CMPSC 473
CMPE Database Systems Exercise #1 Solutions
CMPE Data Structures and Algorithms in C++ May 10 Class Meeting
Lecture 13: Producer-Consumer and Semaphores
Lecture 11: Mutual Exclusion
MODERN OPERATING SYSTEMS Third Edition ANDREW S
Lecture 14: Pthreads Mutex and Condition Variables
Multithreading Tutorial
Jonathan Walpole Computer Science Portland State University
CMPE 135: Object-Oriented Analysis and Design December 6 Class Meeting
Pthread Prof. Ikjun Yeom TA – Mugyo
CMPE 135: Object-Oriented Analysis and Design November 29 Class Meeting Department of Computer Engineering San Jose State University Fall 2018 Instructor:
CMPE 135: Object-Oriented Analysis and Design November 29 Class Meeting Department of Computer Engineering San Jose State University Fall 2018 Instructor:
Concurrency: Mutual Exclusion and Process Synchronization
Multithreading Tutorial
CSE 451: Operating Systems Autumn Lecture 8 Semaphores and Monitors
Multithreading Tutorial
Monitors Chapter 7.
Lecture 14: Pthreads Mutex and Condition Variables
Lecture 13: Producer-Consumer and Semaphores
Lecture 11: Mutual Exclusion
CS333 Intro to Operating Systems
Semaphores Reference text: Tanenbaum ch
CS 144 Advanced C++ Programming May 7 Class Meeting
“The Little Book on Semaphores” Allen B. Downey
CMPE 152: Compiler Design May 2 Class Meeting
Presentation transcript:

CMPE 135: Object-Oriented Analysis and Design April 30 Class Meeting Department of Computer Engineering San Jose State University Spring 2019 Instructor: Ron Mak www.cs.sjsu.edu/~mak

Unofficial Field Trip Computer History Museum in Mt. View http://www.computerhistory.org/ Provide your own transportation to the museum. Saturday, May 4, 11:30 – closing time Special free admission. We will meet in the lobby. No backpacks. Experience a fully restored IBM 1401 mainframe computer from the early 1960s in operation. Do a self-guided tour of the Revolution exhibit.

Presentation Schedule Next Week Tuesday, May 7 .Emojis .JARS .Dragoon Icy .Say Agile One More Time Thursday, May 9 .Extras .Benedict + 3 .No Name 1

Multithreaded Programming Multithreading is a way for an executing program (called a process) to have multiple simultaneous execution paths (called threads). Because the threads all run within one process, they have share resources such as memory. Multithreading allows a program to distribute work among multiple CPUs (cores) to be done concurrently or in parallel. Most computers today are multicore.

Multithreaded Programming, cont’d A programmer who only knows how to do single-threaded programming may already be obsolete. However, multithreaded programming is still hard to do correctly. Few programming languages have built-in support for multithreaded programming. C requires a library to do it. C++ 2011 has a spartan concurrency API.

Concurrency vs. Parallelism In multithreaded programming, multiple threads in effect execute simultaneously. Parallelism: If the computer hardware and operating system can supporting it, the threads are actually executing simultaneously. Concurrency: The hardware and OS support rapidly switching execution among the threads. Both cases must deal with shared resources.

Multithreaded Programming, cont’d Code, data (memory), and files are shared! http://wbuttutorials.com/wbut-tutorials-multithreading.php

Race Condition If multiple threads are executing and sharing resources, how can we prevent one thread from “stepping” on another thread? Example: Thread A is setting the value of variable X while Thread B is also setting the value of variable X. Race condition: The value of variable X depends on the order of execution of Thread A and Thread B. It can be random!

Critical Region Critical region: The statements of a thread that access a given shared resource (such as shared variable X). AKA critical section Do not confuse a critical region with the shared resource. Multiple threads can share a piece of data. Their critical regions may contain different code, but they all share the resource.

Critical Regions and Shared Resources The statements of a thread that access the shared resource is that thread’s critical region with respect to that shared data. What the code in the critical regions have in common is that they access the same shared piece of data. Another shared resource would be associated with another set of critical regions.

Mutual Exclusion To protect the integrity of a shared resource, we must use the principle of mutual exclusion. If one thread is in its critical region and is writing to the shared resource (such as setting the value of a shared variable), no other thread is allowed in its critical region. No other thread can read or write the shared resource. Each of the other threads must wait to enter its critical region for that shared resource (it’s blocked from entering).

Mutual Exclusion, cont’d http://cse.csusb.edu/tongyu/courses/cs460/notes/interprocess.php

Mutual Exclusion, cont’d Multiple threads can be in their critical regions if they are only reading the shared resource (such as getting the value of a shared variable). Since the shared resource is not changing, there is no race condition.

Mutexes A thread uses a mutex object to enforce a critical region and protect a shared resource. Before entering the critical region, the thread attempts to lock the mutex. The thread successfully locks the mutex and enters the critical region if no other thread has already locked the mutex. Otherwise, if the mutex is already locked, the thread must wait until the mutex is unlocked, at which time the thread can attempt to lock the mutex and then enter its critical region.

Mutexes, cont’d When the thread is done executing in the critical region, it must unlock the mutex. Failure to unlock a mutex can cause a deadlock.

To Prevent Race Conditions Mutual exclusion: No two threads may be simultaneously inside their critical regions modifying the same shared data. Progress: No thread running outside its critical region may block other threads. Bounded waiting: No thread should have to wait forever to enter its critical region.

To Prevent Race Conditions, cont’d When a thread is in its critical region in order to modify the shared resource, other threads must be blocked from entering their critical regions. No assumptions may be made about the number of CPUs or their speeds.

Sleep and Wakeup A race condition with shared variable count: void producer() { for (;;) { item = produce_item(); if (count == N) sleep(); insert_item(item); count++; if (count == 1) { wakeup(consumer); } void consumer() { for (;;) { if (count == 0) sleep(); item = remove_item(); count--; if (count == N-1) { wakeup(producer); } consume_item(item); A race condition with shared variable count: The buffer is empty, so the consumer sees count to be 0. Right then, the producer runs, increments count to 1, and tries to wake up the consumer. The consumer is already awake, so the wakeup call is wasted. The consumer runs again. It saw count was 0, and so goes to sleep. The producer fills up the buffer and never wakes up the consumer. The program eventually deadlocks.

Semaphores A semaphore is used to synchronize the actions of multiple threads. Sleep and wakeup calls fail to synchronize threads. Semaphores often require hardware support. One thread waits (blocks) on a semaphore. Another thread signals a semaphore. Any thread waiting on the semaphore unblocks. Signal and wait are analogous to wakeup and sleep, except that signals are not wasted.

Pthreads Package The POSIX standard for threads is implemented by the Pthreads package. Actually, the PThreads function names are all in lower case: pthread_create, pthread_exit, pthread_attr_init, etc. Modern Operating Systems, 3rd ed. Andrew Tanenbaum (c) 2008 Prentice-Hall, Inc.. 0-13-600663-9 All rights reserved

Pthreads Package Pthread threads Pthreads mutexes pthread_t professorThreadId; pthread_attr_t profAttr; pthread_attr_init(&profAttr); pthread_create(&professorThreadId, &profAttr, professor, &professor_id); pthread_join(professorThreadId, NULL); pthread_mutex_t chair_mutex; pthread_mutex_init(&chair_mutex, NULL) pthread_mutex_lock(&chair_mutex); pthread_mutex_unlock(&chair_mutex);

Pthreads Package, cont’d Pthreads semaphores are called condition variables. pthread_cond_t  student_arrived_semaphore; pthread_cond_wait(&student_arrived_semaphore, &semaphore_mutex); pthread_cond_signal(&student_arrived_semaphore);

Example Multithreaded Program Professor Zemma Fore is extremely popular with her students! During each of her office hours, students line up to visit her in order to get help and advice. Prof. Fore has a small office. Inside, there is room for only one student to visit. Outside her office, there are three chairs for students to sit and wait their turns.

Example: During an Office Hour At the start of the hour, Prof. Fore opens her door for office visits. Students arrive at random times. Prof. Fore sees students in the order that they arrive. Each visit with the professor lasts a random time: 1, 2, 3, 4, or 5 minutes.

Example: During an Office Hour, cont’d At the end of a visit, the next waiting student (if any) immediately enters Prof. Fore’s office for a visit. Whenever there are no students visiting or waiting, Prof. Fore works on the design of her programming language “ParFore” for her parallel programming course.

Example: Whenever a Student Arrives If Prof. Fore is not already meeting with another student, the arriving student can immediately start an office visit. If Prof. Fore is already meeting with another student, the arriving student sits down on an empty chair outside her office to wait. If there are no empty chairs, the student leaves. Students who leave don’t return.

Example: At the End of the Office Hour If Prof. Fore is not meeting a student, she closes her door and no more students can visit. If she is meeting a student, she allows that visit to complete (which may take her past her closing time) before closing her door. Any students still waiting then leave.

Example Multithreaded Program, cont’d A program to simulate students visiting Prof. Fore during one of her office hours. Uses the Pthreads library. 1 second of real time = 1 minute of simulation time.

Example Multithreaded Program, cont’d The program prints a message with a timestamp as each event occurs. Events: a student arrives, a student starts an office visit, a student completes an office visit, etc. Tabular output format that shows for each event: The simulation time Which student (if any) is meeting with the professor Which students (if any) are waiting in the chairs Event description Will Prof. Fore ever find time during the hour to work on her language ParFore the course?

Example Multithreaded Program, cont’d The program contains a subtle threading bug! Causes a deadlock under certain circumstances. Can you find the error and correct it? Demo