{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

lecture2 - CSCC69H Lecture 2 Dan Zingaro Feedback from...

Info icon This preview shows pages 1–9. Sign up to view the full content.

View Full Document Right Arrow Icon
CSCC69H Lecture 2 Dan Zingaro May 10, 2010
Image of page 1

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

View Full Document Right Arrow Icon
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.?”
Image of page 2
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.
Image of page 3

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

View Full Document Right Arrow Icon
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
Image of page 4
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
Image of page 5

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

View Full Document Right Arrow Icon
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!
Image of page 6
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
Image of page 7

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

View Full Document Right Arrow Icon
Lock Variables Let the threads share an integer variable lock initialized to 0.
Image of page 8
Image of page 9
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}