Download Operating System - Lecture Slides | COP 4600 and more Study notes Operating Systems in PDF only on Docsity!
COP4600 : Operating Systems Joohan Lee
COP 4600 (Sec 1): Operating Systems
Lecture 11
School of Computer Science University of Central Florida
Instructor : Joohan Lee [email protected]
http://www.cs.ucf.edu/~jlee/cop
COP4600 : Operating Systems Joohan Lee
Chapter 6 – Concurrent Programming
Outline
6.1 Introduction
6.2 Monitors
6.2.1 Condition Variables
6.2.2 Simple Resource Allocation with Monitors
6.2.3 Monitor Example: Circular Buffer
6.2.4 Monitor Example: Readers and Writers
6.3 Java Monitors
6.4 Java Multithreading Case Study, Part III:
Producer/Consumer Relationship in Java
6.5 Java Multithreading Case Study, Part IV:
Circular Buffer in Java
COP4600 : Operating Systems Joohan Lee
Objectives
- After reading this chapter, you should understand:
- how monitors synchronize access to data.
- how condition variables are used with monitors.
- solutions for classic problems in concurrent programming such as readers and writers and circular buffer.
- Java monitors.
- remote procedure calls.
COP4600 : Operating Systems Joohan Lee
6.2.1 Introduction
- Recent interest in concurrent programming languages
- Naturally express solutions to inherently parallel problems
- Due to proliferation of multiprocessing systems, distributed systems and massively parallel architectures
- More complex than standard programs
- More time required to write, test and debug
COP4600 : Operating Systems Joohan Lee
Semaphore
- Is Semaphore better than previous solutions like
Peterson’s?
- Does Semaphore provide an appropriate solution to the
critical section problem?
- What would be the drawbacks, if any, of Semaphore?
- Is there other better way than Semaphore?
COP4600 : Operating Systems Joohan Lee
Producer Process
do { … produce an item in nextp … wait(empty); wait(mutex); … add nextp to buffer … signal(mutex); signal(full); } while (1);
do { wait(full) wait(mutex); … remove an item from buffer to nextc … signal(mutex); signal(empty) … consume the item in nextc … Recall producer/consumer problem} while (1); Use three semaphores semaphore full = 0; empty = n, mutex = 1;
Consumer Process
COP4600 : Operating Systems Joohan Lee
Motivation
- Semaphores and Events are:
- Powerful but low-level abstractions
- Programming with them is highly error prone
- Such programs are difficult to design, debug, and maintain
- Not usable in distributed memory systems
- Need higher-level primitives
- Based on semaphores or messages
COP4600 : Operating Systems Joohan Lee
Monitors
- To make it easier to write correct concurrent programs,
Hoare (1974) and Brinch Hansen (1976) proposed a
higher level synchronization primitive called monitor
- Monitor
- A collection of procedures, variables, and data structures that are all grouped together in a special kind of module or package
- Follow principles of abstract data type (object-oriented)
COP4600 : Operating Systems Joohan Lee
6.2 Monitors
- Monitor
- Contains data and procedures needed to allocate shared resources - Accessible only within the monitor - No way for threads outside monitor to access monitor data
- Resource allocation using monitors
- T hread must call monitor entry routine
- Mutual exclusion is rigidly enforced at monitor boundary
- A thread that tries to enter monitor when it is in use must wait
- Threads return resources through monitors as well
- Monitor entry routine calls signal
- Alerts one waiting thread to acquire resource and enter monitor
- Higher priority given to waiting threads than ones newly arrived
- Avoids indefinite postponement
COP4600 : Operating Systems Joohan Lee
Monitors
- High-level synchronization construct that allows the safe sharing of an abstract data type among concurrent processes. monitor monitor-name { shared variable declarations procedure body P1 (…) { ... } procedure body P2 (…) { ... } procedure body Pn (…) { ... } { initialization code } }
COP4600 : Operating Systems Joohan Lee
Monitors
- Monitor is a programming language construct
- It’s up to the compiler to implement the mutual exclusion on monitor entries (using binary semaphores in general)
- The compiler, not the programmer, arranges for the mutual exclusion Æ less error prone
- Implementation must guarantee:
- Resource accessible only by monitor procedures
- Monitor procedures are mutually exclusive
- At any time, only one process may be executing a procedure within a given monitor
- Only one process (thread) may be inside a monitor at a time
COP4600 : Operating Systems Joohan Lee
Condition Variables
- Is mutual exclusion enough for our requirements?
- (ex) In producer-consumer problem, what if the buffer is full and the producer has to block?
- (ex) what if the buffer is empty and the consumer has to block?
- It does not provide any means for processes to
communicate or synchronize with one another
- Inside the monitor, use a conditional variable
- Introducing condition variables
- wait & signal operations on the conditional variables
- A process inside the monitor can block on the condition variables and allow another process to enter the monitor
COP4600 : Operating Systems Joohan Lee
Hoare’s Semantics
Effect of wait
COP4600 : Operating Systems Joohan Lee
Hoare’s Semantics
Effect of signal
COP4600 : Operating Systems Joohan Lee
c.wait(); // p1 blocks
…
// p1 resumes exit();
c.signal(); // p2 blocks
…
… // p2 resumes exit();
Hoare’s Semantics
P1 P
Monitor
- Let the newly awakened process run, suspending the process that called signal
- The process that called signal is given the highest priority and reenters the monitor as soon as the reactivated process leaves the monitor
COP4600 : Operating Systems Joohan Lee
c.wait(); // p1 blocks
exit(); // p1 resumes
c.signal() // p2 continues … exit(); // p2 finishes
Hansen’s Semantics
P1 P
Monitor
- A process doing a SIGNAL must exit the monitor immediately
- SIGNAL can appear only as the final statement in a monitor procedure
- Conceptually simpler and easier to implement
COP4600 : Operating Systems Joohan Lee
Bounded buffer problem
monitor BoundedBuffer {
char buffer[n];
int nextin=0, nextout=0, fullCount=0;
condition notempty, notfull;
deposit(char data) {
remove(char data) {
COP4600 : Operating Systems Joohan Lee
Bounded buffer problem
deposit(char data) {
if (fullCount==n) notfull.wait;
buffer[nextin] = data;
nextin = (nextin+1) % n;
fullCount = fullCount+1;
notempty.signal;
remove(char data) {
if (fullCount==0) notempty.wait;
data = buffer[nextout];
nextout = (nextout+1) % n;
fullCount = fullCount - 1;
notfull.signal;
COP4600 : Operating Systems Joohan Lee
6.2.3 Monitor Example: Circular Buffer
- Circular buffer implementation of the solution to
producer/consumer problem
- Producer deposits data in successive elements of array
- Consumer removes the elements in the order in which they were deposited (FIFO)
- Producer can be several items ahead of consumer
- If the producer fills last element of array, it must “wrap around” and begin depositing data in the first element of array
COP4600 : Operating Systems Joohan Lee
6.2.3 Monitor Example: Circular Buffer
- Due to the fixed size of a circular buffer
- Producer will occasionally find all array elements full, in which case the producer must wait until consumer empties an array element
- Consumer will occasionally find all array elements empty, in which case the consumer must wait until producer deposits data into an array element
COP4600 : Operating Systems Joohan Lee
6.2.3 Monitor Example: Circular Buffer Figure 6.2 Monitor pseudocode implementation of a circular buffer. (Part 1 of 2.)
COP4600 : Operating Systems Joohan Lee
Figure 6.2 Monitor pseudocode implementation of a circular buffer. (Part 2 of 2.)
6.2.3 Monitor Example: Circular Buffer
COP4600 : Operating Systems Joohan Lee
6.2.4 Monitor Example: Readers and
Writers
- Readers
- Read data, but do not change contents of data
- Multiple readers can access the shared data at once
- When a new reader calls a monitor entry routine, it is allowed to proceed as long as no thread is writing and no writer thread is waiting to write
- After the reader finishes reading, it calls a monitor entry routine to signal the next waiting reader to proceed, causing a “chain reaction”
- Writers
- Can modify data
- Must have exclusive access
COP4600 : Operating Systems Joohan Lee
Figure 6.3 Monitor pseudocode for solving the readers and writers problem. (Part 1 of 3.)
6.2.4 Monitor Example: Readers and
Writers
