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

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)

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.

Planning a meeting

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

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

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

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

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