lecture2 - CSCC69H Lecture 2 Dan Zingaro May 10, 2010...

Info iconThis preview shows pages 1–9. 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 2 Dan Zingaro May 10, 2010 Feedback from Reading Quiz I “I find it interesting how average response time can be improved by switching threads midway while another process is executing. It seems counter-intuitive to have to stop and switch to another thread... (having to save states, memory, etc)” I “A semaphore does not correspond to PTHREAD_MUTEX_RECURSIVE . They work in opposite directions. A semaphore decrements when it tries to lock a thread and increments when it tries to unlock a thread, while PTHREAD_MUTEX_RECURSIVE increments when locking and decrements when unlocking.” I “Why not just throw an exception every time a mutex is used incorrectly, rather than providing PTHREAD_MUTEX_RECURSIVE , PTHREAD_MUTEX_ERRORCHECK , etc.?” Mutual Exclusion Given: I A set of threads, T0 , T1 , . . . , Tn I A set of resources shared between threads I A segment of code which accesses the shared resources, called the critical section (CS) We want to ensure that only one thread at a time can execute in the CS. Critical Section Requirements 1. Mutual exclusion I At most one process is executing its critical section at any time 2. Absence of deadlock I It is impossible to reach a state in which some processes are trying to enter their critical sections, but no process is successful 3. Absence of starvation I If a process is trying to execute its critical section, then eventually that process is successful Critical Section Problem I Design a protocol that threads can use to cooperate I Each thread must request permission to enter its CS, in its entry section I CS may be followed by an exit section I Remaining code is the remainder section I Each thread is executing at non-zero speed I Make no assumptions about relative speed Interrupts I What if each process disabled interrupts prior to entering its CS and enabled them just before leaving? I This would prevent the CPU from switching to another process I But giving user processes the ability to disable all interrupts is dangerous! Assumptions and Notation I Assume no special hardware instructions, and no restrictions on the number of processors (for now) I Assume that basic machine language instructions (LOAD, STORE, etc.) are atomic I If two such instructions are executed concurrently, the result is equivalent to their sequential execution in some order I On modern architectures, this assumption may be false I If only two threads, we number them T0 and T1 I Use Ti to refer to one thread, Tj for the other ( j = 1 - i) when the exact numbering doesn’t matter Lock Variables Let the threads share an integer variable lock initialized to 0. My_work(id_t id) { /* id_t is 0 or 1 */ ......
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 / 35

lecture2 - CSCC69H Lecture 2 Dan Zingaro May 10, 2010...

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

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