A Discipline of Multiprogramming: Programming Theory for Distributed Applications by Jayadev Misra

1. A Discipline of Multiprogramming: Programming Theory for Distributed Applications by Jayadev Misra Chapter 1, Mikhail Nesterenko

2. Programming model • claim: the major difficulty in programming a distributed application is not the number of computing entities but the inherent complexity of concurrent programming • idea: to simplify (multi) programming separate sequential and concurrent aspects of programming • model (Seuss): program execution is understood as single thread of control • program is reasoned about as sequential execution of actions (or methods) • implementation permits concurrent execution of multiple threads (actions)

3. Implications of Seuss • possible to reason about sequential execution only (one action at a time) • implementation can be concurrent • need theory to formalize when concurrent execution is equivalent to serial • efficiency becomes an issue (serial execution may degrade performance) • no explicit need for concurrency control tools: synchronization, rendezvous, waiting, sharing, mutual exclusion, locking, etc.

4. Planning a meeting

5. Correctness and performance of plan • sequential correctness: plan is correct when no other programs are executing • “easy” to prove, not the central issue of the book, use “traditional” sequential programming theories • concurrent correctness • tradeoff between efficiency and ease of reasoning – the problem trivializes when each instance of plan gains exclusive access to shared data

6. Model again • program – set of objects • object – set of procedures (professor and room are objects): action or method • action – a unit of uninterrupted execution, wait-free (action never stops or waits), terminating (always terminates) • method – same as action only action is autonomous and method is called (object professor includes methods next and reserve) • no need for locking, or other explicit consideration for concurrency

7. Efficient implementation: concurrency • objective – implementation of efficient concurrent execution while preserving equivalence to serial execution • independent actions – do not share objects, can be executed concurrently • compatible actions (less strict) – concurrent execution of compatible action is equivalent to (some) serial execution • p.next and q.next are compatible (for all professors and rooms) • p.next and q.reserve are not • task of programmer – specify compatible actions

8. Efficient implementation: termination • what if resource is unavailable for a method to complete? (note, this never happens to actions, why?) • can’t wait • has to issue reject • total method (transformational program) – always completes, never rejects • sorting an array of (non-shared) integers • partial method(reactive?) – may issue reject • rejection is transient condition (may change), acceptance is permanent • if methods may reject, weaker compatibility is possible

9. Summary • programming individual actions has been done before • this book is the study in concurrent composition of actions and methods