1. Lecture 7 Page 1 CS 111 Online Process Communications and Concurrency CS 111 On-Line MS Program Operating Systems Peter Reiher

2. Lecture 7 Page 2 CS 111 Online Outline Why do processes need to communicate? What mechanisms do they use for communication? What kinds of problems does such communications lead to?

3. Lecture 7 Page 3 CS 111 Online Processes and Communications Many processes are self-contained – Or only need OS services to share hardware and data But many others need to communicate – To other processes – To other machines Often complex applications are built of multiple processes – Which need to communicate

4. Lecture 7 Page 4 CS 111 Online Types of Communications Simple signaling – Just telling someone else that something has happened – E.g., letting go of a lock Messages – Occasional exchanges of information Procedure calls or method invocation Tight sharing of large amounts of data – E.g., shared memory, pipes

5. Lecture 7 Page 5 CS 111 Online Some Common Characteristics of IPC There are issues of proper synchronization – Are the sender and receiver both ready? – Issues of potential deadlock There are safety issues – Bad behavior from one process should not trash another process There are performance issues – Copying of large amounts of data is expensive There are security issues, too

6. Lecture 7 Page 6 CS 111 Online Potential Trouble Spots We’re breaking the boundaries between processes – Can we still ensure safety and security? Interprocess communication implies more sophisticated synchronization – Better not mess it up Moving data between entities usually involves copying – Too much copying is expensive

7. Lecture 7 Page 7 CS 111 Online Desirable Characteristics of Communications Mechanisms Simplicity – Simple definition of what they do and how to do it – Good to resemble existing mechanism, like a procedure call – Best if they’re simple to implement in the OS Robust – In the face of many using processes and invocations – When one party misbehaves Flexibility – E.g., not limited to fixed size, nice if one-to-many possible, etc. Free from synchronization problems Good performance Usable across machine boundaries

8. Lecture 7 Page 8 CS 111 Online Blocking Vs. Non-Blocking When sender uses the communications mechanism, does it block waiting for the result? – Synchronous communications Or does it go ahead without necessarily waiting? – Asynchronous communications Blocking reduces parallelism possibilities – And may complicate handling errors Not blocking can lead to more complex programming – Parallelism is often confusing and unpredicatable Particular mechanisms tend to be one or the other

9. Lecture 7 Page 9 CS 111 Online Communications Mechanisms Signals Sharing memory Messages RPC More sophisticated abstractions – The bounded buffer

10. Lecture 7 Page 10 CS 111 Online Signals A very simple (and limited) communications mechanism Essentially, send an interrupt to a process – With some kind of tag indicating what sort of interrupt it is Depending on implementation, process may actually be interrupted Or may have some non-interrupting condition code raised – Which it would need to check for

11. Lecture 7 Page 11 CS 111 Online Properties of Signals Unidirectional Low information content – Generally just a type – Thus not useful for moving data – Intended to, well, signal things Not always possible for user processes to signal each other – May only be used by OS to alert user processes – Or possibly only through parent/child process relationships

12. Lecture 7 Page 12 CS 111 Online What Is Typically Done With Signals? Terminating processes – Cleanly or otherwise Notifying parents of child termination Notifying of I/O errors and other I/O situations Telling processes they did something invalid – E.g., illegal addresses Linux provides a couple of user-definable signals Windows makes little use of signals

13. Lecture 7 Page 13 CS 111 Online Implementing Signals Typically through the trap/interrupt mechanism OS (or another process) requests a signal for a process That process is delivered a trap or interrupt implementing the signal There’s no associated parameters or other data – So no need to worry about where to put or find that

14. Lecture 7 Page 14 CS 111 Online Sharing Memory Everyone uses the same pool of RAM anyway Why not have communications done simply by writing and reading parts of the RAM? – Sender writes to a RAM location – Receiver reads it – Give both processes access to memory via their domain registers Conceptually simple Basic idea cheap to implement Usually non-blocking

15. Lecture 7 Page 15 CS 111 Online Processor Memory Network Disk Sharing Memory With Domain Registers Process 1 Process 2 With write permission for Process 1 And read permission for Process 2

16. Lecture 7 Page 16 CS 111 Online Using the Shared Domain to Communicate Processor Memory Network Disk Process 1 Process 2 Process 1 writes some data Process 2 then reads it

17. Lecture 7 Page 17 CS 111 Online Potential Problem #1 With Shared Domain Communications Processor Memory Network Disk Process 1 Process 2 How did Process 1 know this was the correct place to write the data? How did Process 2 know this was the correct place to read the data?

18. Lecture 7 Page 18 CS 111 Online Potential Problem #2 With Shared Domain Communications Processor Memory Network Disk Process 1 Process 2 What if Process 2 tries to read the data before process 1 writes it? Timing Issues Worse, what if Process 2 reads the data in the middle of Process 1 writing it?

19. Lecture 7 Page 19 CS 111 Online And the Problems Can Get Worse What if process 1 wants to write more data than the shared domain can hold? What if both processes wish to send data to each other? – Give them read/write on the single domain? – Give them each one writeable domain, and read permission on the other’s? What if it’s more than two processes? Just scratches the surface of potential problems

20. Lecture 7 Page 20 CS 111 Online The Core Difficulty This abstraction is too low level It leaves too many tricky problems for the application writers to solve The OS needs to provide higher level communications abstractions – To hide complexities and simplify the application writers’ lives There are many possible choices here

21. Lecture 7 Page 21 CS 111 Online Messages A conceptually simple communications mechanism The sender sends a message explicitly The receiver explicitly asks to receive it The message service is provided by the operating system – Which handles all the “little details” Usually non-blocking

22. Lecture 7 Page 22 CS 111 Online Operating System Using Messages Processor Memory Network Disk Process 1 Process 2 SEND RECEIVE

23. Lecture 7 Page 23 CS 111 Online Advantages of Messages Processes need not agree on where to look for things – Other than, perhaps, a named message queue Clear synchronization points – The message doesn’t exist until you SEND it – The message can’t be examined until you RECEIVE it – So no worries about incomplete communications Helpful encapsulation features – You RECEIVE exactly what was sent, no more, no less No worries about size of the communications – Well, no worries for the user; the OS has to worry Easy to see how it scales to multiple processes

24. Lecture 7 Page 24 CS 111 Online Implementing Messages The OS is providing this communications abstraction There’s no magic here – Lots of stuff needs to be done behind the scenes – And the OS has to do it Issues to solve: – Where do you store the message before receipt? – How do you deal with large quantities of messages? – What happens when someone asks to receive before anything is sent? – What happens to messages that are never received? – How do you handle naming issues? – What are the limits on message contents?

25. Lecture 7 Page 25 CS 111 Online Message Storage Issues Messages must be stored somewhere while waiting delivery – Typical choices are either in the sender’s domain What if sender deletes/overwrites them? – Or in a special OS domain That implies extra copying, with performance costs How long do messages hang around? – Delivered ones are cleared – What about those for which no RECEIVE is done? One choice: delete them when the receiving process exits

26. Lecture 7 Page 26 CS 111 Online Message Receipt Synchronization When RECEIVE issued for non-existent message – Block till message arrives – Or return error to the RECEIVE process Can also inform processes when messages arrive – Using interrupts or other mechanism – Only allow RECEIVE operations for arrived messages

27. Lecture 7 Page 27 CS 111 Online A Big Advantage of Messages Reasonable choice for communicating between processes on different machines If you use them for everything, you sort of get distributed computing for free – Not really, unfortunately – But at least the interface remains the same