29 April 2002 Operating Systems Distributed Computing Chapter 17 ------------ ------------------- Models of distributed computing Message passing/remote procedure call/distributed objects/shared memory Message Passing inter process communication instead of using internally shared memory, use network protocols need buffering of messages need format for message contents unicast/multicast client/server paradigm, peer to peer computing programs focused around i/o Remote Procedure Call dist programs should look as close to centralized programs as possible implemented as a set of network protocols conventional: blocking calls executes in different address spaces can also do non-blocking calls, make call, then continue execution. typically there is a synchronization call that the caller can execute to determine if the remote call has completed parameters: typically passed by value/result parameter marshalling to change machine format if necessary pointers usually not allowed as parameters must locate the remote procedure can be known at compile time: host:port dynamic binding is widely used: use a lookup mechanism (lookup server) Distributed Objects Java RMI, Corba perform lookup and get remote reference to object make calls on this remote reference looks like RPC differences? Shared memory tuple spaces - Javaspaces, TSpaces Interweave simulate one large name space =================== Keeping time for synchronization individual clocks move out of synch in a centralized system, if procss B asks for the time after process A B's time will be "later" than A. ALWAYS CONSISTENT The same is not true in a distributed system where A and B run on different processors But we want a mechanism for distributed systems which is always consistent Event Ordering: what we care about, is the order events occurred, not "time" a model for what it means to be consistent Happened Before A->B a) A --> B, A executed before B, in same process b) A --> B, A send msg x, B recv msg x c) A --> B and B --> C, then A --> C order of concurrent ops not important implementation: common clock perfectly synchronized, impossible timestamp - virtual clock A->B def. timestamp of A < timestamp of B Per process logical clock counter incremented on each event can break ties by defining an order of the processors Mutual exclusion structures common on single host (e.g., semaphore, monitor) not practical centralized Algorithm server (coordinator) request reply release basically the coordinator keeps a queue similar to a semaphore + mutual exclusion guaranteed, FIFO, fair, no starvation + easy to implement, only 3 messages - coordinator is single point of failure - coordinator may become bottleneck failure of coordinator - elect new leader, reconstruct request queue failure of locker, coordinator can monitor fully distributed use logical time stamps Pj sends request(Pj, TS) to all processes, waits for reply a. Pi in CS ---> no reply yet b. Pi does not want into CS ---> reply immediately c. Pi wants in --> compare TS Pi > Pj - immediate reply Pj asked first Pi < Pj - delay reply + mutex obtained + no deadlock + no starvation + no more bottleneck - num msgs 2(N-1) proven minimum - all procs must participate -- must know one another -- adding new proc is hard - failure of one node -> system collapses - can monitor node liveness - procs not in CS must take time to respond to others + good for small, stable sets of procs token passing put processes in a logical ring pass token can go into CS only if hold token unidirectional ring - no starvation if no one wants into CS, lots of msgs! if all want into CS, msg cost = 1 failures: token lost - generate new one (election) node failure - recreate ring