Distributed Operating Systems CS551 Colorado State University at Lockheed-Martin Lecture 3 -- Spring 2001

7 February 2001CS-551, Lecture 32 CS551: Lecture 3 n Topics – Real Time Systems (and networks) – Interprocess Communication (IPC) n message passing n pipes n sockets n remote procedure call (RPC) – Memory Management

7 February 2001CS-551, Lecture 33 Real-time systems n Real-time systems: – systems where “the operating system must ensure that certain actions are taken within specified time constraints” Chow & Johnson, Distributed Operating Systems & Algorithms, Addison-Wesley (1997). – systems that “interact with the external world in a way that involves time … When the answer is produced is as important as which answer is produced.” Tanenbaum, Distributed Operating Systems, Prentice-Hall (1995).

7 February 2001CS-551, Lecture 34 Real-time system examples n Examples of real-time systems – automobile control systems – stock trading systems – computerized air traffic control systems – medical intensive care units – robots – space vehicle computers (space & ground) – any system that requires bounded response time

7 February 2001CS-551, Lecture 35 Soft real-time systems n Soft real-time systems – “missing an occasional deadline is all right” Tanenbaum, Distributed Operating Systems, Prentice-Hall (1995). – “have deadlines but are judged to be in working order as long as they do not miss too many deadlines” Chow & Johnson, Distributed Operating Systems & Algorithms, Addison-Wesley (1997). – Example: multimedia system

7 February 2001CS-551, Lecture 36 Hard real-time systems n Hard real-time systems – “only judged to be correct if every task is guaranteed to meet its deadline” Chow & Johnson, Distributed Operating Systems & Algorithms, Addison-Wesley (1997). – “a single missed deadline … is unacceptable, as this might lead to loss of life or an environ- mental catastrophe” Tanenbaum, Distributed Operating Systems, Prentice-Hall (1995).

7 February 2001CS-551, Lecture 37 Hard/Soft real-time systems n “A job should be completed before its deadline to be of use (in soft real-time systems) or to avert disaster (in hard real- time systems). The major issue in the design of real-time operating systems is the scheduling of jobs in such a way that a maximum number of jobs satisfy their deadlines.” Singhal & Shivaratri, Advanced Concepts in Operating Systems, McGraw-Hill (1994).

7 February 2001CS-551, Lecture 38 Firm real-time systems n Firm real-time systems – “similar to a soft real-time system, but tasks that have missed their deadlines are discarded” Tanenbaum, Distributed Operating Systems, Prentice-Hall (1995). – “where missing a deadline means you have to kill off the current activity, but the consequence is not fatal” Chow & Johnson, Distributed Operating Systems & Algorithms, Addison-Wesley (1997). – E.g. partially filled bottle on assembly line

7 February 2001CS-551, Lecture 39 Types of real-time systems n Re-active: – interacts with environment n Embedded: – controls specialized hardware n Event-triggered: – unpredictable, asynchronous n Time-Triggered: – predictable, synchronous, periodic

7 February 2001CS-551, Lecture 310 Myths of real-time systems (Tanenbaum) n “Real-time systems are about writing device drivers in assembly code.” – involve more than device drivers n “Real-time computing is fast computing.” – computer-powered telescopes n “Fast computers will make real-time systems obsolete.” – no -- only more will be expected of them

7 February 2001CS-551, Lecture 311 Message passing n A form of communication between two processes n A physical copy of message is sent from one process to the other n Blocking vs Non-blocking

7 February 2001CS-551, Lecture 312 Blocking message passing n Sending process must wait after send until an acknowledgement is made by the receiver n Receiving process must wait for expected message from sending process n A form of synchronization n Receipt determined – by polling common buffer – by interrupt

7 February 2001CS-551, Lecture 313 Figure 3.1 Blocking Send and Receive Primitives: No Buffer. (Galli, p.58)

7 February 2001CS-551, Lecture 314 Figure 3.2 Blocking Send and Receive Primitives with Buffer. (Galli, p.58)

7 February 2001CS-551, Lecture 315 Non-blocking message passing n Asynchronous communication n Sending process may continue immediately after sending a message -- no wait needed n Receiving process accepts and processes message -- then continues on n Control – buffer -- receiver can tell if message still there – interrupt

7 February 2001CS-551, Lecture 316 Process Address n One-to-one addressing – explicit – implicit n Group addressing – one-to-many – many-to-one – many-to-many

7 February 2001CS-551, Lecture 317 One-to-one Addressing n Explicit address – specific process must be given as parameter n Implicit address – name of service used as parameter – willing to communicate with any client – acts like send_any and receive_any

7 February 2001CS-551, Lecture 318 Figure 3.3 Implicit Addressing for Interprocess Communication. (Galli, p.59)

7 February 2001CS-551, Lecture 319 Figure 3.4 Explicit Addressing for Interprocess Communication. (Galli,p.60)

7 February 2001CS-551, Lecture 320 Group addressing n One-to-many – one sender, multiple receivers – broadcast n Many-to-one – multiple senders, but only one receiver n Many-to-many – difficult to assure order of messages received

7 February 2001CS-551, Lecture 321 Figure 3.5 One-to-Many Group Addressing. (Galli, p.61)

7 February 2001CS-551, Lecture 322 Many-to-many ordering n Incidental ordering – least structured, fastest – acceptable if all related messages received in any order n Uniform ordering – all receivers receive messages in same order n Universal ordering – all messages must be received in exactly the same order as sent

7 February 2001CS-551, Lecture 323 Figure 3.6 Uniform Ordering. (Galli, p.62)

7 February 2001CS-551, Lecture 324 Pipes n “interprocess communication APIs” n “implemented by a finite-size, FIFO byte- stream buffer maintained by the kernel” n “serves as a unidirectional communication link so that one process can write data into the tail end of the pipe while another process may read from the head end of the pipe” n Chow & Johnson, Distributed Operating Systems & Algorithms, Addison-Wesley (1997).

7 February 2001CS-551, Lecture 325 Pipes, continued n “created by a pipe system call, which returns two pipe descriptors (similar to a file descriptor), one for reading and the other for writing … using ordinary write and read operations” (C&J) n “exists only for the time period when both reader and writer processes are active” (C&J) n “the classical producer and consumer IPC problem” (C&J)

7 February 2001CS-551, Lecture 326 Figure 3.7 Interprocess Communication Using Pipes. (Galli, p.63)

7 February 2001CS-551, Lecture 327 Unnamed pipes n “Pipe descriptors are shared by related processes” (e.g. parent, child) – Chow & Johnson, Distributed Operating Systems & Algorithms, Addison-Wesley (1997). n Such a pipe is considered unnamed n Cannot be used by unrelated processes – a limitation

7 February 2001CS-551, Lecture 328 Named pipes n “For unrelated processes, there is a need to uniquely identify a pipe since pipe descriptors cannot be shared. One solution is to replace the kernel pipe data structure with a special FIFO file. Pipes with a path name are called named pipes.” (C&J) n “Since named pipes are files, the communicating processes need not exist concurrently” (C&J)

7 February 2001CS-551, Lecture 329 Named pipes, continued n “Use of named pipes is limited to a single domain within a common file system.” (C&J) – a limitation – …. Therefore, sockets….

7 February 2001CS-551, Lecture 330 Sockets n “a communication endpoint of a communication link managed by the transport services” (C&J) n “created by making a socket system call that returns a socket descriptor for subsequent network I/O operations, including file- oriented read/write and communication- specific send/receive” (C&J)

7 February 2001CS-551, Lecture 331 Figure 1.4 The ISO/OSI Reference Model. (Galli, p.9)

7 February 2001CS-551, Lecture 332 Sockets, continued n “A socket descriptor is a logical communication endpoint (LCE) that is local to a process; it must be associated with a physical communication endpoint (PCE) for data transport. A physical communication endpoint is specified by a network host address and transport port pair. The association of a LCE with a PCE is done by the bind system call.” (C&J)

7 February 2001CS-551, Lecture 333 Types of socket communication n Unix – local domain – a single system n Internet – world-wide – includes port and IP address

7 February 2001CS-551, Lecture 334 Types, continued n Connection-oriented – uses TCP n “a connection-oriented reliable stream transport protocol” (C&J) n Connectionless – uses UDP n “a connectionless unreliable datagram transport protocol” (C&J)

7 February 2001CS-551, Lecture 335 Connection-oriented socket communication socket request Client n Adapted from Chow & Johnson bind listen accept read write read connect socket Server reply rendezvous

7 February 2001CS-551, Lecture 336 Connectionless socket communication Peer Processes LCE Peer Processes PCE LCE PCE bind socket Sendto /recvfrom socket bind n Adapted from Chow & Johnson

7 February 2001CS-551, Lecture 337 Socket support n Unix primitives – socket, bin, connect, listen, send, receive, shutdown – available through C libraries n Java classes – Socket – ServerSocket

7 February 2001CS-551, Lecture 338 Figure 3.8 n Socket n Analogy n (Galli,p.66)

7 February 2001CS-551, Lecture 339 Figure 3.9 Remote Procedure Call Stubs. (Galli,p.73)

7 February 2001CS-551, Lecture 340 Figure 3.10 Establishing Communication for RPC. (Galli,p.74)

7 February 2001CS-551, Lecture 341 Table 3.1 Summary of IPC Mechanisms and Their Use in Distributed System Components. n (Galli, p.77)

7 February 2001CS-551, Lecture 342 Memory Management n Review n Simple memory model n Shared memory model n Distributed shared memory n Memory migration

7 February 2001CS-551, Lecture 343 Virtual memory (pages, segments) n Virtual memory n Memory management unit n Pages - uniform sized n Segments - of different sizes n Internal fragmentation n External fragmentation

7 February 2001CS-551, Lecture 344 Figure 4.1 Fragmentation in Page-Based Memory versus a Segment-Based Memory. (Galli, p.83)

7 February 2001CS-551, Lecture 345 Page replacement algorithms n Page fault n Thrashing n First fit n Best fit – LRU (NRU) – second chance n Worst fit

7 February 2001CS-551, Lecture 346 Figure 4.2 n Algorithms n for n Choosing n Segment n Location n (Galli,p.84)

7 February 2001CS-551, Lecture 347 Simple memory model n Parallel UMA systems – thrashing can occur when parallel processes each want its own pages in memory – time to service all memory requests expensive, unless memory large – virtual memory expensive – caching can be expensive

7 February 2001CS-551, Lecture 348 Shared memory model n NUMA n Memory bottleneck n Cache consistency – Snoopy cache – enforce critical regions – disallow caching shared memory data

7 February 2001CS-551, Lecture 349 Figure 4.3 n Snoopy n Cache n (Galli, p.89)

7 February 2001CS-551, Lecture 350 Distributed shared memory n BBN Butterfly n Reader-writer problems

7 February 2001CS-551, Lecture 351 Figure 4.4 Centralized Server for Multiple Reader/Single Writer DSM. (Galli,p.92)

7 February 2001CS-551, Lecture 352 Figure 4.5 Partially Distributed Invalidation for Multiple Reader/Single Writer DSM. (Galli, p.92)

7 February 2001CS-551, Lecture 353 Ffigure 4.6 Dynamic Distributed Multiple Reader/Single Writer DSM. (Galli, P.93)

7 February 2001CS-551, Lecture 354 Figure 4.7 Dynamic Data Allocation for Multiple Reader/Single Writer DSM. (Galli,p.96)

7 February 2001CS-551, Lecture 355 Figure 4.8 Stop-and-Copy Memory Migration. (Galli,p.99)