8.1 Introduction<\/p>\n
Processes that cooperate in order to complete one or more tasks almost always need to communicate with each other. Sometimes the communication requires sharing data. One method of sharing data is by sharing a common file. If at least one of the processes modifies the \u001cfile, then the fi\u001cle must be accessed in mutual exclusion. Sharing a fi\u001cle is essentially like sharing a memory-resident<\/a> resource in that both are a form of communication that uses a shared resource that is accessed in mutual exclusion. Another paradigm involves passing data back and forth through some type of communication channel that provides the required mutual exclusion. A pipe is an example of this, as is a socket. This type of communication is broadly known as a message-passing<\/a> solution to the problem.<\/p>\n This chapter is concerned only with message-passing types of communication. We will begin with unnamed pipes, after which we will look at named pipes, also known as FIFO<\/a> ‘s, and then look at sockets. Part I is exclusively related to pipes.<\/p>\n 8.2 Unnamed Pipes<\/p>\n You are familiar with how to use pipes at the command level. A command such as<\/p>\n $ last | grep ‘reboot’<\/p>\n connects the output of last to the input of grep, so that the only lines of output will be those lines of last that contain the word ‘reboot’. The ‘|’ is a bash operator; it causes bash to start the last command and the grep command simultaneously, and to direct the standard output of last into the standard input of grep.<\/p>\n Although ‘|’ is a bash operator, it uses the lower-level, underlying pipe facility of UNIX<\/a>, which was invented by Douglas Mcilroy<\/a>, and was incorporated into UNIX in 1973. You can visualize the pipe mechanism as a special file or buffer that acts quite literally like a physical pipe, connecting the output of last to the input of grep, as in Figure 8.1.<\/p>\n The last program does not know that it is writing to a pipe and grep does not know that it is reading from a pipe. Moreover, if last tries to write to the pipe faster than grep can drain it, last will block, and if grep tries to read from an empty pipe because it is reading faster than last can write, grep will block, and both of these actions are handled behind the scenes by the kernel.<\/p>\n What then is a pipe? Although a pipe may seem like a fi\u001cle, it is not a fi\u001cle, and there is no \u001cfile pointer associated with it. It is conceptually like a conveyor belt consisting of a \u001cfixed number of logical blocks that can be filled and emptied. Each write to the pipe \u001cfills as many blocks as are needed to satisfy it, provided that it does not exceed the maximum pipe size, and if the pipe size limit was not reached, a new block is made available for the next write. Filled blocks are conveyed to the read-end of the pipe, where they are emptied when they are read. These types of pipes are called unnamed pipes because they do not exist anywhere in the \u001cfile system. They have no names.<\/p>\n An unnamed pipe1 in UNIX is created with the pipe() system call.<\/p>\n #include <unistd.h> int pipe(int filedes[2]);<\/p>\n The system call pipe(fd), given an integer array fd of size 2, creates a pair of fi\u001cle descriptors, fd[0] and fd[1], pointing to the “read-end” and “write-end” of a pipe inode respectively. If it is successful, it returns a 0, otherwise it returns -1. The process can then write to the write-end, fd[1], using the write() system call, and can read from the read-end, fd[0], using the read() system call. The read and write-ends are opened automatically as a result of the pipe() call. Written data are read in \u001cfirst-in-fi\u001crst-out (FIFO) order. The following program (pipedemo0.c in the demos directory) demonstrates this simple case.<\/p>\n","protected":false},"excerpt":{"rendered":"