Inter-Process Communication

Transcription

1 CS 326: Operating Systems Inter-Process Communication Lecture 10

2 Today s Schedule Shared Memory Pipes 2/28/18 CS 326: Operating Systems 2

3 Today s Schedule Shared Memory Pipes 2/28/18 CS 326: Operating Systems 3

4 Shared Memory When we use pthreads, we have accessed to a shared memory pool Heap memory We can also share regions of memory between processes! Unlike with pthreads, we can restrict sharing to a particular region of memory 2/28/18 CS 326: Operating Systems 4

5 mmap Mapping a region of memory is accomplished by the mmap function mmap asks the OS kernel to reserve a portion of memory and allow other process(es) to access it It s also possible to memory map a file In fact, mmap() takes in a file descriptor More efficient than reading/writing buffered data to/from disk manually 2/28/18 CS 326: Operating Systems 5

6 Working with Mapped Memory After the call to mmap completes, participating processes are given a void pointer This pointer provides the first offset of the shared memory region Processes can read/write directly as if they are working with their own memory space 2/28/18 CS 326: Operating Systems 6

7 Use Cases Mapped memory is extremely efficient Once set up, processes do not have to go through the kernel to communicate Better performance It s also more error-prone than other IPC mechanisms If a cooperating program writes to memory incorrectly, it s game over 2/28/18 CS 326: Operating Systems 7

8 Today s Schedule Shared Memory Pipes 2/28/18 CS 326: Operating Systems 8

9 Pipes Pipes are a common way for programs to communicate on Unix systems Most useful for sharing unstructured data (such a text) between processes Work like how they sound: if you want to send data to another process, send it through the pipe Pipes fit in to the general Unix I/O landscape 2/28/18 CS 326: Operating Systems 9

10 Input/Output Streams Each program gets allocated three streams by default: stdout (standard output) stderr (standard error) stdin (standard input) As with most things in Unix, these are represented as files (file descriptors) These streams have different functions 2/28/18 CS 326: Operating Systems 10

11 stdout When you call printf, you are writing to stdout This stream is designed for general program output; for example, if you type ls then the list of files should display on stdout You can pipe stdout to other programs: ls -l / grep 'bin' or redirect to a file: ls -l / > list_of_files.txt 2/28/18 CS 326: Operating Systems 11

12 stderr The standard error stream is used for diagnostic information This way, program output can still be passed to other programs/files but we ll still see diagnostics printed to the terminal Helps us know when something went wrong Unlike stdout, stderr is not buffered 2/28/18 CS 326: Operating Systems 12

13 stdin The final stream, stdin, one way to provide program input (via scanf, for example) This can be entered by the user, or we can pipe input directly into a program: ls -l / grep 'bin' Writes file list to stdout Reads file list from stdin, Writes matching files to stdout 2/28/18 CS 326: Operating Systems 13

14 I/O Buffering (1/2) Input/output operations are expensive: they have high latency Printing to the terminal is outputting data to the standard output stream Writing to disk or controlling an external hardware device are also I/O operations These devices generally operate on buffers Example: our serial console has a 2-byte buffer; we fill up the buffer before asking it to print the text 2/28/18 CS 326: Operating Systems 14

15 I/O Buffering (2/2) You may have used buffered streams in Java to get better performance You might have also noticed what happens when you forget to close a stream Buffered I/O collects multiple I/O operations, combines them, and then executes them Important: matching up with hardware capabilities 2/28/18 CS 326: Operating Systems 15

16 fprintf We can control where printed output goes with fprintf File printf stderr is actually a file in fact, on Unix systems most devices are represented as files Try ls /dev to view the devices on your machine (includes macos) So if we want to write data to a file, just pass it in: fprintf(file, "My name is: %s", "Bob"); 2/28/18 CS 326: Operating Systems 16

17 The pipe function Now back to pipes: we can create them with the pipe() function Returns a set of file descriptors: the input and output sides of the pipe Pipes aren t very useful if they aren t connected to anything, though We can do this by fork()ing another process 2/28/18 CS 326: Operating Systems 17

18 Piping to another Process After calling fork(), both processes have a copy of the pipe file descriptors Pipes only operate in one direction, though, so we need to close the appropriate ends of the pipe You can think of a forked() pipe as one with four ends: two input and output ends each We eliminate the ends we don t need to control the direction of data flow > --- < 2/28/18 CS 326: Operating Systems 18

19 Controlling Flow To control data flow through the pipe, we have to close the ends we won t use For example: Child process closes FD 0 and reads from FD 1 Parent process closes FD 1 and writes to FD 0 2/28/18 CS 326: Operating Systems 19

20 Async Process Creation You may be wondering: what good are pipes when we have to start all the cooperating processes? There s actually another option: FIFOs, aka named pipes Create with the mkfifo command, then open as you would a regular file descriptor 2/28/18 CS 326: Operating Systems 20

21 Redirecting Output: dup2 dup2 allows us to redirect output streams int dup2(int fildes, int fildes2); Let s say we want to make our standard output stream go through the pipe we just created We ll do: dup2(fd[0], STDOUT_FILENO); 2/28/18 CS 326: Operating Systems 21

22 Redirecting to a File We can also redirect output to a file instead: int output = open("output.txt", O_CREAT O_WRONLY, 0666); dup2(output, STDOUT_FILENO); Cool, right? Ok, let s try this out 2/28/18 CS 326: Operating Systems 22