01:198:214 Lecture Notes - Lecture 7: Increment And Decrement Operators, Edsger W. Dijkstra
//-------Notes For Systems Programming 10/19/17--------\\
Mutexes - synch on code block(critical section)
barrier - synch on max value of counter (code segment/region/area in code)
(computation)
operation: increment counter and reset counter
- All threads to hit barrer incrememnt it
- Last thread to incrememt barrier incrememnts it to the max/target value ... it
resets the barrier
- Once barrier is rest, increment call returns and all get to continue
primitive : fetch-and-increment ^
read(),Write() non-blocking
Condition Variables - synch on an event (p_thread cond wait() )
signal - One will be woken up
broadcast - Everyone who is waiting will be woken upper
operation: wait until something occurs
- All threads calling wait block until condition
- Condition is signalled by a detector thread calling signal() (to wake up one)
or broadcast() (to wake up all)
primitive: compare-and-swap ^
//-------Synchronization Plus Logic-------\\
Monitor
- Object-Oriented synchronization supervisor
- Monitor is given all primitives and crontrols access to them
- If a thread wants access to a resource, ask monitor
//-------Edsger Dijkstra-------\\
Semaphores
p() - Decrement consumer/wait
v() - incrememt producer/notify
sem_wait() - Decrement shared counter ... blocks if shared counter is 0
| Blocks on both sides on 0
sem_notify() - Incremet shared coutner ... blocks if shared counter is at some
max value | and on max value
//-------Building a Mutex out of semaphores-------\\
Asynchronous threadsafe (!!!! 8^D)
lock(s) | Deadlocks yourself
lock(s) | (VERY BAD)
Vs.
sem_notify(m) | It may block the thread or carry on (nothing bad)
sem_notify(m) | depends on max value
unlock(s) | UNDEFINED behavior
unlock(s) | (VERY BAD)
Vs.
sem_wait(m) | It may block the thread or carry on (nothing bad)
sem_wait(m) | depends on max value
great for asynchronous ooperations
TA TB
lock(m) unlock(m) - Problem each lock t_id (thread id) is stamped on
the mutex only that thread can unlock it thus causing an error in runtime if TB
tries to unlock a locked mutex by TA
sem_wait(s) sem_notify(s) - No problem
Only use semaphores inside of a signal handler
find more resources at oneclass.com
find more resources at oneclass.com
Document Summary
Mutexes - synch on code block(critical section) barrier - synch on max value of counter (code segment/region/area in code) (computation) operation: increment counter and reset counter. All threads to hit barrer incrememnt it. Last thread to incrememt barrier incrememnts it to the max/target value it resets the barrier. Once barrier is rest, increment call returns and all get to continue primitive : fetch-and-increment ^ read(),write() non-blocking. Condition variables - synch on an event (p_thread cond wait() ) signal - one will be woken up broadcast - everyone who is waiting will be woken upper operation: wait until something occurs. All threads calling wait block until condition. Condition is signalled by a detector thread calling signal() (to wake up one) or broadcast() (to wake up all) primitive: compare-and-swap ^ Monitor is given all primitives and crontrols access to them. If a thread wants access to a resource, ask monitor.
