



























Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Major points from this lecture are: Concurrent Programs, Recursive Algorithms, Safety and Liveness, Mutual Exclusion, Synchronization, Determinism, Linearizability, Deadlock, Deadlock Avoidance, Priorité a Droite . Object-Oriented Programming and Data Structures course includes program structure and organization, object oriented programming, graphical user interfaces, algorithm analysis, recursion, data structures (lists, trees, stacks, queues, heaps, search trees, hash tables, graphs), simple g
Typology: Lecture notes
1 / 35
This page cannot be seen from the preview
Don't miss anything!




























We saw that in general, recursion matches with the notion of an inductive proof
We still want proofs of correctness - Techniques arenât identical but we often use induction - Induction isnât the only way to prove things
Leslie Lamport suggested that we think about the question in terms of safety and liveness -
program is safe if nothing bad happens. The guarantee that concurrently accessed memory will be locked first is a safety property.
The property is also called mutual exclusion -
program is live if good things eventually happen. The guarantee that all threads get to make progress is a liveness property
Consider a program with multiple threads in it - Perhaps threads
and
They share some objects
First, we need to ask if the shared objects are thread safe - Every access protected by synchronized()
Hardware needs synchronization too!
Suppose that a program correctly locks all accesses to shared objects, or uses volatile correctly - Would it now be safe? - Issue that arises involves interleavings
This is desirable
This is confusing and can signal problems
Start with your concurrent program - But prove that it behaves like a non â concurrent program that does the same operations in some âlinearâ order - Idea behind proof: if the effect of two executions is the same, then we can treat them as equivalent
Recall from last week - Deadlock depends on four conditions -
wait
for cycle
Locks that are held until the thread finishes what it wants to do, not released - No preemption of locks - Mutual exclusion
Suppose that threads acquire locks in some standard order. Thm: deadlock cannot occur!
Slightly oversimplified proof: A deadlock means that there is some cycle of threads A, BâŠ. T each waiting for the next to take some action. - Consider thread A and assume A holds lock X a . - A is waiting on B: A wants a lock X b and B holds that lock. - Now look at B: it holds X b and wants X .c^ - We eventually get to thread T that holds X t^ and wants X a - But per our rules X a < X b < âŠ. X t^ < X a :^ a contradiction! QED - Notice that this is similar to an inductive argument docsity.com
Paris traffic circles: Deadlock in action
Paris has a strange rule at some traffic circles: priorité a droite - Traffic circles around, say, the Arc de Triomphe - Roads enter from the right - You must yield to let them enter
Paris traffic circle: priorité a droite
An issue at Place dâEtoile and Place Victor Hugo (rest of France uses prioritĂ© a gauche ) - Think of cars as threads and âspaceâ as objects - If thread
occupies a space that thread
wishes to enter, then
waits for
Under this rule, deadlocks can form!
To see this, look for a wait â for cycle
Why is priorité a droite a bad rule?
Why is priorité a droite a bad rule? Ooh la la! Quel catastrophe!