lecture3 - CSCC69H Lecture 3 Dan Zingaro May 17, 2010...

Info iconThis preview shows pages 1–8. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: CSCC69H Lecture 3 Dan Zingaro May 17, 2010 Feedback from Reading Quiz I Last lecture, we used Petersons algorithm to solve the critical section problem for two threads I Can we use it for three or more threads? I Yes, but it gets more complicated. I have trouble convincing myself that the two-thread version is correct! I Instead of doing this, we instead use locks, semaphores, or monitors Reading Quiz: Queuing Mutexes I The queuing mutexes you read about have three components I state : 1 for unlocked, 0 for locked I waiters : a queue for threads waiting to acquire the mutex I spinlock : protects state and waiters I If state were not protected by a spinlock, two threads might both find state == 1 and both lock it by setting it to 0. Race condition! I Before accessing state or waiters , a thread must continue spinning (using an atomic operation like test-and-set) until it locks spinlock Reading Quiz: Queuing Mutexes... ... To lock the mutex: lock mutex.spinlock (in cache-conscious fashion) if mutex.state = 1 then let mutex.state = 0 unlock mutex.spinlock else add current thread to mutex.waiters remove current thread from runnable threads unlock mutex.spinlock yield to a runnable thread ... To unlock mutex: lock mutex.spinlock (in cache-conscious fashion) if mutex.waiters is empty then let mutex.state = 1 else move one thread from mutex.waiters to runnable unlock mutex.spinlock Monitors I A monitor is an object that has a mutex, locked whenever a method is called and unlocked afterward I Other processes that attempt to enter monitor are blocked, waiting for the monitor mutex I Local data can be accessed only by the monitors procedures (not by any external procedure) I This guarantees mutual exclusion I In Java, synchronized is close to the monitor concept Complication with Monitors I A thread in the monitor may need to wait for something to happen I e.g. while invoking a procedure in the monitor, data from another thread may be required I But that other thread may require access to the monitor to produce that data! I There must be a way to suspend execution within the monitor I wait() : atomically release lock and suspend invoking process I signal() : resume exactly one suspended process Monitors......
View Full Document

This note was uploaded on 02/05/2011 for the course CS 69 taught by Professor Cathy during the Summer '10 term at University of Toronto- Toronto.

Page1 / 27

lecture3 - CSCC69H Lecture 3 Dan Zingaro May 17, 2010...

This preview shows document pages 1 - 8. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online