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

Slides:



Advertisements
Similar presentations
Categories of I/O Devices
Advertisements

Processes Management.
Operating Systems Lecture 7.
Executional Architecture
Lecture 13 Page 1 CS 111 Online File Systems: Introduction CS 111 On-Line MS Program Operating Systems Peter Reiher.
WHAT IS AN OPERATING SYSTEM? An interface between users and hardware - an environment "architecture ” Allows convenient usage; hides the tedious stuff.
©2009 Operačné systémy Procesy. 3.2 ©2009 Operačné systémy Process in Memory.
Lecture 12 Page 1 CS 111 Online Devices and Device Drivers CS 111 On-Line MS Program Operating Systems Peter Reiher.
Informationsteknologi Wednesday, September 26, 2007 Computer Systems/Operating Systems - Class 91 Today’s class Mutual exclusion and synchronization 
Lecture 3 Page 1 CS 239, Spring 2001 Interprocess Communications in Distributed Operating Systems CS 239 Distributed Operating Systems April 9, 2001.
490dp Synchronous vs. Asynchronous Invocation Robert Grimm.
Page 1 Processes and Threads Chapter Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.
1: Operating Systems Overview
3.5 Interprocess Communication Many operating systems provide mechanisms for interprocess communication (IPC) –Processes must communicate with one another.
Inter Process Communication:  It is an essential aspect of process management. By allowing processes to communicate with each other: 1.We can synchronize.
3.5 Interprocess Communication
Processes 1 CS502 Spring 2006 Processes Week 2 – CS 502.
02/01/2010CSCI 315 Operating Systems Design1 Interprocess Communication Notice: The slides for this lecture have been largely based on those accompanying.
Threads CS 416: Operating Systems Design, Spring 2001 Department of Computer Science Rutgers University
Lecture 18 Page 1 CS 111 Online Design Principles for Secure Systems Economy Complete mediation Open design Separation of privileges Least privilege Least.
Lecture 5 Page 1 CS 111 Summer 2014 Process Communications, Synchronization, and Concurrency CS 111 Operating Systems Peter Reiher.
LOGO OPERATING SYSTEM Dalia AL-Dabbagh
Operating System Review September 10, 2012Introduction to Computer Security ©2004 Matt Bishop Slide #1-1.
Lecture 4 Page 1 CS 111 Spring 2015 Modularity and Virtualization CS 111 Operating Systems Peter Reiher.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
CE Operating Systems Lecture 11 Windows – Object manager and process management.
Operating Systems Lecture 7 OS Potpourri Adapted from Operating Systems Lecture Notes, Copyright 1997 Martin C. Rinard. Zhiqing Liu School of Software.
Lecture 11 Page 1 CS 111 Online Memory Management: Paging and Virtual Memory CS 111 On-Line MS Program Operating Systems Peter Reiher.
1 Lecture 5 (part2) : “Interprocess communication” n reasons for process cooperation n types of message passing n direct and indirect message passing n.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
CE Operating Systems Lecture 13 Linux/Unix interprocess communication.
Lecture 8 Page 1 CS 111 Online Other Important Synchronization Primitives Semaphores Mutexes Monitors.
Deadlock Detection and Recovery
1: Operating Systems Overview 1 Jerry Breecher Fall, 2004 CLARK UNIVERSITY CS215 OPERATING SYSTEMS OVERVIEW.
Computer Architecture and Operating Systems CS 3230: Operating System Section Lecture OS-4 Process Communication Department of Computer Science and Software.
Lecture 5 Page 1 CS 111 Online Processes CS 111 On-Line MS Program Operating Systems Peter Reiher.
Lecture 18 Page 1 CS 111 Online OS Use of Access Control Operating systems often use both ACLs and capabilities – Sometimes for the same resource E.g.,
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Lecture 7 Page 1 CS 111 Winter 2014 Process Communications and Concurrency CS 111 Operating Systems Peter Reiher.
Lecture 7 Page 1 CS 111 Fall 2015 Process Communications and Concurrency CS 111 Operating Systems Peter Reiher.
Lecture 4 Page 1 CS 111 Online Modularity and Virtualization CS 111 On-Line MS Program Operating Systems Peter Reiher.
Lecture 4 Mechanisms & Kernel for NOSs. Mechanisms for Network Operating Systems  Network operating systems provide three basic mechanisms that support.
Lecture 9 Page 1 CS 111 Online Deadlock Prevention Deadlock avoidance tries to ensure no lock ever causes deadlock Deadlock prevention tries to assure.
Lecture 7 Page 1 CS 111 Spring 2015 Process Communications and Concurrency CS 111 Operating Systems Peter Reiher.
Lecture9 Page 1 CS 236 Online Operating System Security, Con’t CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
Operating Systems Unit 2: – Process Context switch Interrupt Interprocess communication – Thread Thread models Operating Systems.
I/O Software CS 537 – Introduction to Operating Systems.
Copyright © Curt Hill More on Operating Systems Continuation of Introduction.
Lecture 10 Page 1 CS 111 Online Memory Management CS 111 On-Line MS Program Operating Systems Peter Reiher.
Lecture 4 Page 1 CS 111 Online Modularity and Memory Clearly, programs must have access to memory We need abstractions that give them the required access.
Lecture 4 Page 1 CS 111 Summer 2013 Scheduling CS 111 Operating Systems Peter Reiher.
Lecture 5 Page 1 CS 111 Summer 2013 Bounded Buffers A higher level abstraction than shared domains or simple messages But not quite as high level as RPC.
Lecture 1 Page 1 CS 111 Summer 2013 Important OS Properties For real operating systems built and used by real people Differs depending on who you are talking.
Lecture 5 Page 1 CS 111 Online Process Creation Processes get created (and destroyed) all the time in a typical computer Some by explicit user command.
Remote Procedure Calls
Modularity Most useful abstractions an OS wants to offer can’t be directly realized by hardware Modularity is one technique the OS uses to provide better.
Kernel Design & Implementation
CS 6560: Operating Systems Design
Outline Other synchronization primitives
Outline What does the OS protect? Authentication for operating systems
Process Creation Processes get created (and destroyed) all the time in a typical computer Some by explicit user command Some by invocation from other running.
Multiple Writers and Races
Swapping Segmented paging allows us to have non-contiguous allocations
Modularity and Memory Clearly, programs must have access to memory
Outline What does the OS protect? Authentication for operating systems
Accessing Remote Sites CS 188 Distributed Systems January 13, 2015
CSE 153 Design of Operating Systems Winter 2019
CS703 – Advanced Operating Systems
Presentation transcript:

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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?

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

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

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

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

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

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?

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

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

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