Parallel Programming Parallel Programming 0024 0024 Recitation - - PowerPoint PPT Presentation

parallel programming parallel programming
SMART_READER_LITE
LIVE PREVIEW

Parallel Programming Parallel Programming 0024 0024 Recitation - - PowerPoint PPT Presentation

Parallel Programming Parallel Programming 0024 0024 Recitation Week 7 Recitation Week 7 Spring Semester 2010 Spring Semester 2010 R 7 :: 1 0024 Spring 2010 Todays program Assignment 6 Assignment 6 Review of semaphores


slide-1
SLIDE 1

– R 7 :: 1 – 0024 Spring 2010

Parallel Programming Parallel Programming

0024 0024

Recitation Week 7 Recitation Week 7 Spring Semester 2010 Spring Semester 2010

slide-2
SLIDE 2

– R 7 :: 2 – 0024 Spring 2010

Today‘s program

Assignment 6 Assignment 6 Review of semaphores Review of semaphores

 Semaphores  Semaphoren and (Java) monitors

Semaphore implementation of monitors (review) Semaphore implementation of monitors (review) Assignment 7 Assignment 7

slide-3
SLIDE 3

– R 7 :: 3 – 0024 Spring 2010

Semaphores

Special Integer variable w/2 atomic operations Special Integer variable w/2 atomic operations

 P()

(Passeren, wait/up)

 V()

(Vrijgeven/Verhogen, signal/down)

Names of operations reflect the Dutch origin of the Names of operations reflect the Dutch origin of the inventor ... inventor ...

slide-4
SLIDE 4

– R 7 :: 4 – 0024 Spring 2010

class Semaphore

public class Semaphore { public class Semaphore { private int value; private int value; public Semaphore() { public Semaphore() { value = 0; value = 0; } } public Semaphore(int k) { public Semaphore(int k) { value = k; value = k; } } public synchronized void P() { /* see next slide */ } public synchronized void P() { /* see next slide */ } public synchronized void V() { /* see next slide */ } public synchronized void V() { /* see next slide */ } } }

slide-5
SLIDE 5

– R 7 :: 5 – 0024 Spring 2010

P() operation

public synchronized void P() { public synchronized void P() { while (value == 0) { while (value == 0) { try { try { wait(); wait(); } } catch (InterruptedException e) { } catch (InterruptedException e) { } } } value --; value --; } }

slide-6
SLIDE 6

– R 7 :: 6 – 0024 Spring 2010

V() operation

public synchronized void V() { public synchronized void V() { ++value; ++value; notifyAll(); notifyAll(); } }

slide-7
SLIDE 7

– R 7 :: 7 – 0024 Spring 2010

Comments

You can modify the value of an semphore instance only You can modify the value of an semphore instance only using the P() and V() operations. using the P() and V() operations.

 Initialize in constructor

Effect Effect

 P() may block  V() never blocks

Application of semaphores: Application of semaphores:

 Mutual exclusion  Conditional synchronization

slide-8
SLIDE 8

– R 7 :: 8 – 0024 Spring 2010

2 kinds of semaphores

Binary semaphore Binary semaphore

 Value is either 0 or 1  Supports implemention of mutual exclusion

Semaphore s = new Semaphore(1); s.p() //critical section s.v() Counting (general) semaphore Counting (general) semaphore

 Value can be any positive integer value

slide-9
SLIDE 9

– R 7 :: 9 – 0024 Spring 2010

Fairness

A semaphore is considered to be “fair“ if all threads A semaphore is considered to be “fair“ if all threads that execute a P() operation eventually succeed. that execute a P() operation eventually succeed. Different models of fairness – Different models of fairness – Semaphore is “unfair”: a thread blocked in the P() Semaphore is “unfair”: a thread blocked in the P()

  • peration must wait forever while other threads (that
  • peration must wait forever while other threads (that

executed the operation later) succeed. executed the operation later) succeed.

slide-10
SLIDE 10

– R 7 :: 10 – 0024 Spring 2010

Semaphores in Java

java.util.concurrent.Semaphore

java.util.concurrent.Semaphore

acquire()

acquire()

instead of instead of P()

P()

release()

release()

instead of instead of V()

V()

Constructors Constructors

Semaphore(int permits);

Semaphore(int permits);

Semaphore(int permits, boolean fair);

Semaphore(int permits, boolean fair);

 permits: initial value  fair: if true then the semphore uses a FIFO to

manage blocked threads

slide-11
SLIDE 11

– R 7 :: 11 – 0024 Spring 2010

Semaphores and monitors

Monitor: model for synchronized methods in Java Monitor: model for synchronized methods in Java Both constructs are equivalent Both constructs are equivalent One can be used to implement the other One can be used to implement the other

slide-12
SLIDE 12

– R 7 :: 12 – 0024 Spring 2010

Example from Mar 18

See slides for context

slide-13
SLIDE 13

– R 7 :: 13 – 0024 Spring 2010

Buffer using condition queues

class BoundedBuffer extends Buffer { public BoundedBuffer(int size) { super(size); } public synchronized void insert(Object o) throws InterruptedException { while (isFull()) { wait(); } doInsert(o); notifyAll(); }

slide-14
SLIDE 14

– R 7 :: 14 – 0024 Spring 2010

Buffer using condition queues,

continued

// in class BoundedBuffer public synchronized Object extract() throws InterruptedException { while (isEmpty()) { wait(); } Object o = doExtract(); notifyAll(); return o; }// extract } // BoundedBuffer

slide-15
SLIDE 15

– R 7 :: 15 – 0024 Spring 2010

Emulation of monitor w/ semaphores

We need 2 semaphores: We need 2 semaphores: One to make sure that only one synchronized method executes One to make sure that only one synchronized method executes at any tiven time at any tiven time

call this the “access semaphore” (access) call this the “access semaphore” (access) binary semaphore binary semaphore

One semaphore to line up threads that are waiting for some One semaphore to line up threads that are waiting for some condition condition

call this the “condition semaphore” (cond) – also binary call this the “condition semaphore” (cond) – also binary threads that wait must do an “acquire” and this will not threads that wait must do an “acquire” and this will not complete complete

For convenience: For convenience:

 Counter waitThread to count number of waiting threads  i.e., threads in queue for cond

slide-16
SLIDE 16

– R 7 :: 16 – 0024 Spring 2010

Basic idea

1) 1) Frame all synchronized methods with access.acquire() and Frame all synchronized methods with access.acquire() and access.release() access.release() This ensures that only one thread executes a synchronized This ensures that only one thread executes a synchronized method at any point in time method at any point in time Recall access is binary. Recall access is binary. 1) 1) Translate wait() and notifyAll() to give threads waiting in line Translate wait() and notifyAll() to give threads waiting in line a chance to progress (these threads use cond) a chance to progress (these threads use cond) To simplify the debate, we require that “notifyAll()” is the To simplify the debate, we require that “notifyAll()” is the last action in a synchronized method last action in a synchronized method Java does not enforce this requirement but the mapping Java does not enforce this requirement but the mapping

  • f synchronized methods into semaphores is simplified.
  • f synchronized methods into semaphores is simplified.
slide-17
SLIDE 17

– R 7 :: 17 – 0024 Spring 2010

Buffer with auxiliary fields

class BoundedBuffer extends Buffer { public BoundedBuffer(int size) { super(size); access = new Semaphore(1); cond = new Semaphore(0); } private Semaphore access; private Semaphore cond; private int waitThread = 0; // continued ... }

slide-18
SLIDE 18

– R 7 :: 18 – 0024 Spring 2010

1) Framing all methods

public void insert(Object o) throws InterruptedException { access.acquire(); //ensure mutual exclusion while (isFull()) { wait(); } doInsert(o); notifyAll(); access.release(); } // insert

slide-19
SLIDE 19

– R 7 :: 19 – 0024 Spring 2010

Notes

There is one semaphore for There is one semaphore for all all synchronized methods synchronized methods

  • f one instance of “BoundedBuffer”
  • f one instance of “BoundedBuffer”

Why? Why?

Must make sure that insert and extract don’t overlap. Must make sure that insert and extract don’t overlap.

There must be separate semaphore to deal with waiting There must be separate semaphore to deal with waiting threads. threads. Why? Why?

Imagine the buffer is full. A thread that attempts to insert Imagine the buffer is full. A thread that attempts to insert an item must wait. But it must release the access semaphore. an item must wait. But it must release the access semaphore. Otherwise a thread that wants to remove an item will not be Otherwise a thread that wants to remove an item will not be able to executed the (synchronized!) extract method. able to executed the (synchronized!) extract method.

slide-20
SLIDE 20

– R 7 :: 20 – 0024 Spring 2010

2) Translate wait and notifyAll

The operation The operation

wait() wait()

is translated into is translated into

waitThread++ waitThread++ access.release(); // other threads can execute methods access.release(); // other threads can execute methods cond.acquire(); // wait until condition changes cond.acquire(); // wait until condition changes access.acquire(); access.acquire(); waitThread-- waitThread--

slide-21
SLIDE 21

– R 7 :: 21 – 0024 Spring 2010

Each occurrrence of Each occurrrence of NotifyAll() NotifyAll() is translated to is translated to for (int i=0; i < waitThread; i++) { for (int i=0; i < waitThread; i++) { cond.release(); cond.release(); } } All threads waiting are released and will compete to All threads waiting are released and will compete to (re)acquire access. (re)acquire access.

They decrement waitThread after they leave cond.acquire They decrement waitThread after they leave cond.acquire Note that to enter the line (i.e., increment waitThread) the Note that to enter the line (i.e., increment waitThread) the thread must hold the access semaphore access thread must hold the access semaphore access

slide-22
SLIDE 22

– R 7 :: 22 – 0024 Spring 2010

Recall that access.release is done at the end of the Recall that access.release is done at the end of the synchronized method synchronized method So all the threads that had lined up waiting for cond So all the threads that had lined up waiting for cond compete to get access to access compete to get access to access No thread can line up while the cond.release No thread can line up while the cond.release

  • perations are done since this thread holds access.
  • perations are done since this thread holds access.
slide-23
SLIDE 23

– R 7 :: 23 – 0024 Spring 2010

Note

We wake up all threads – they might not be able to We wake up all threads – they might not be able to enter their critical section if the condition they waited enter their critical section if the condition they waited for does not hold. But all threads get a chance. for does not hold. But all threads get a chance.

 This approach is different from what we discussed in the

lecture

slide-24
SLIDE 24

– R 7 :: 24 – 0024 Spring 2010

Translate “wait()”

public void insert(Object o) throws InterruptedException { access.acquire(); while (isFull()) { waitThread++; access.release(); // let other thread access object cond.acquire(); // wait for change of state access.acquire() waitThread--; } doInsert(o); notifyAll(); access.release(); }

slide-25
SLIDE 25

– R 7 :: 25 – 0024 Spring 2010

Translate “notifyAll()”

public void insert(Object o) throws InterruptedException { access.acquire();

while (isFull()) { waitThread ++; access.release(); // let other thread access object cond.acquire(); // wait for change of state access.acquire() waitThread --;

} doInsert(o); for (int i; i < waitThread; i++) { cond.release(); } access.release(); } // insert

slide-26
SLIDE 26

– R 7 :: 26 – 0024 Spring 2010

Example

Consider the buffer, one slot is empty, four operations Consider the buffer, one slot is empty, four operations insert I1 insert I1 insert I2 insert I2 insert I3 insert I3 extract E extract E I1 – access.acquire I1 – access.acquire I2 – access.acquire: blocks on access I2 – access.acquire: blocks on access I3 – access.acquire: blocks on access I3 – access.acquire: blocks on access I1 – waitThread == 0 I1 – waitThread == 0 I1.release I1.release

slide-27
SLIDE 27

– R 7 :: 27 – 0024 Spring 2010

(cont)

I2 – access.acquire completes I2 – access.acquire completes I2 – buffer full I2 – buffer full waitThread =1 waitThread =1 I2 – access.release I2 – access.release I2 – cond.acquire – blocks on cond I2 – cond.acquire – blocks on cond I3 – access.acquire completes I3 – access.acquire completes I3 – buffer full I3 – buffer full waitThread = 2 waitThread = 2 I3 – access.release I3 – access.release I3 – cond.acquire – blocks on cond I3 – cond.acquire – blocks on cond

slide-28
SLIDE 28

– R 7 :: 28 – 0024 Spring 2010

(cont)

E – access.acquire E – access.acquire remove item remove item E – cond.release E – cond.release E – cond.release E – cond.release E – access.release E – access.release One of I2 or I3 will succeed with access.acquire and be One of I2 or I3 will succeed with access.acquire and be able to insert the next item able to insert the next item

slide-29
SLIDE 29

– R 7 :: 29 – 0024 Spring 2010

Exercise

How would the method “extract” look like (if we used How would the method “extract” look like (if we used semaphores to emulate monitors)? semaphores to emulate monitors)?

slide-30
SLIDE 30

– R 7 :: 30 – 0024 Spring 2010

Assignment 7

Hint: Hint: Thread.currentThread() Thread.currentThread() returns a handle to returns a handle to the current thread and might be useful for the the current thread and might be useful for the assignment. assignment.

slide-31
SLIDE 31

– R 7 :: 31 – 0024 Spring 2010

Overview

Your task is to implement a Read/Write Lock Your task is to implement a Read/Write Lock

  • Max. 4 Threads
  • Max. 4 Threads
  • Max. 2 Reader Threads (shared access is allowed) and
  • Max. 2 Reader Threads (shared access is allowed) and

1 Writer Thread 1 Writer Thread A thread that executes read() is a reader A thread that executes read() is a reader At a later time it can be a writer .... At a later time it can be a writer ....

slide-32
SLIDE 32

– R 7 :: 32 – 0024 Spring 2010

The challenge

No starvation No starvation Efficient implementation Efficient implementation

 If there are fewer than 2 readers and no waiting writers then

the next reader must be allowed to proceed

 If there is no contention then a thread must be allowed to

proceed immediately

Your implementation must be fair (you may want to use Your implementation must be fair (you may want to use FIFOQueue.java) FIFOQueue.java)

slide-33
SLIDE 33

– R 7 :: 33 – 0024 Spring 2010

Other comments

Keep your solution as simple as possible Keep your solution as simple as possible Decide what you want to use [your decision] Decide what you want to use [your decision]

 Monitors (synchronized methods)  Semaphores

http://java.sun.com/j2se/1.5.0/docs/api/ Semaphore

Only change class Monitor.java Only change class Monitor.java

 If you feel it‘s necessary to change other files, please let us

  • know. 

Please comment your code! Please comment your code!

slide-34
SLIDE 34

– R 7 :: 34 – 0024 Spring 2010

You may want to recall

Thread.currentThread().getId() Thread.currentThread().getId()

 wait_list.enq(Thread.currentThread().getId())  wait_list.getFirstItem() == Thread.currentThread().getId()

slide-35
SLIDE 35

– R 7 :: 35 – 0024 Spring 2010

Your log could look like this …

READ LOCK ACQUIRED 1 READ LOCK ACQUIRED 1 READ LOCK RELEASED 0 READ LOCK RELEASED 0 WRITE LOCK ACQUIRED 1 WRITE LOCK ACQUIRED 1 WRITE LOCK RELEASED 0 WRITE LOCK RELEASED 0 READ LOCK ACQUIRED 1 READ LOCK ACQUIRED 1 READ LOCK ACQUIRED 2 READ LOCK ACQUIRED 2 READ LOCK RELEASED 1 READ LOCK RELEASED 1 READ LOCK ACQUIRED 2 READ LOCK ACQUIRED 2 READ LOCK RELEASED 1 READ LOCK RELEASED 1 READ LOCK ACQUIRED 2 READ LOCK ACQUIRED 2