Please enable JavaScript.
Coggle requires JavaScript to display documents.
Lecture 9: Locks Semaphores Mutexes and object locking Performance…
Lecture 9:
Locks
Semaphores
Mutexes and object locking
Performance
Locks
Basics
Process
Obtain Lock
If unable to wait
Do critical section work
Release Lock
Issues locks fix
Preemptive tasks messing with shared resources
Tasks being done in the wrong order due to multiple processes running
Semaphores
Basics
Properties
A counter
Previously locks used flags
A counter can be any number so it allows more flexibility
If NEGATIVE it adds process to waiting queue
A waiting FIFO queue
The operations to wake up once it can
Two methods
Wait
Decrements counter
If negative it adds process to waiting queue
If >= 0 then it returns
Post
Increment counter
If queue is non empty wake one up
Simple and only handle a few features
Use
Exclusion locking
Counter must be initialized at 1
Wait now await completion
Post now means wake process
Notification/Async Waits
Counter is initialized at 0
Wait now means take lock
Post now means release lock
Mutexes and object locking
Basics
Mutexes are mutually exclusive locks
Means only one process can hold lock at a time
Issues
With complex code and data structures we'd need to block off the entire data object
We did this with one of our labs where we needed to lock the object entirely since it was shared with multiple threads
Getting good performance with locking
Two basic issues with Locks
Overhead
The work it takes to have a locking system
Already highly optimized
Many built in options with this in mind
Contention
Processes fighting with other processes to obtain locks
Solutions
Eliminate the critical section entirely
Eliminate shared resources
Give everyone their own locks
Use atomic instructions
Only possible if simple enough instructions
Eliminate preemption during critical section
If it doesn't jump around in the middle of code we'd have no issues
Disable interrupts
Reduce time spent in critical section
This decreases the chances of being preempted inside the critical section
Reduce frequency of entering critical section
Reduce exclusive use of the serialized resource
Read/Write locks
We don't need to worry about changing data if we're only reading
Spread requests out over more resources
Simpler and more idiot proof but causes more contention
Mars Rover Problem
Problem:
Actual problem that happened
An oversight led to handling priorities poorly
Slide 33 and 37 Lecture 9
Basically the lower priority had the lock and later was unable to release the lock when a higher level priority was running preventing a lock
Solution
Increase the priority of the current task to the level of the high priority that is locked
This process is called
priority inheritance