Question

Given the following code:

int main(int argc, char *argv[])
{
    int pipefd[2];
    pid_t cpid;
    char buf;

    if (argc != 2) {
        fprintf(stderr, "Usage: %s \n", argv[0]);
        exit(EXIT_FAILURE);
    }

    if (pipe(pipefd) == -1) {
        perror("pipe");
        exit(EXIT_FAILURE);
    }

    cpid = fork();
    if (cpid == -1) {
        perror("fork");
        exit(EXIT_FAILURE);
    }

    if (cpid == 0) {    /* Child reads from pipe */
        close(pipefd[1]);          /* Close unused write end */

        while (read(pipefd[0], &buf, 1) > 0)
            write(STDOUT_FILENO, &buf, 1);

        write(STDOUT_FILENO, "\n", 1);
        close(pipefd[0]);
        _exit(EXIT_SUCCESS);

    } else {            /* Parent writes argv[1] to pipe */
        close(pipefd[0]);          /* Close unused read end */
        write(pipefd[1], argv[1], strlen(argv[1]));
        close(pipefd[1]);          /* Reader will see EOF */
        wait(NULL);                /* Wait for child */
        exit(EXIT_SUCCESS);
    }
return 0;

}

Whenever the child process wants to read from the pipe, it must first close the pipe’s side from writing. When I remove that line close(pipefd[1]); from the child process’s if,
I’m basically saying that “okay, the child can read from the pipe, but I’m allowing the parent to write to the pipe at the same time”?

If so, what would happen when the pipe is open for both reading & writing? No mutual exclusion?

Answer 1

Whenever the child process wants to read from the pipe, it must first close the pipe’s side from writing.

If the process — parent or child — is not going to use the write end of a pipe, it should close that file descriptor. Similarly for the read end of a pipe. The system will assume that a write could occur while any process has the write end open, even if the only such process is the one that is currently trying to read from the pipe, and the system will not report EOF, therefore. Further, if you overfill a pipe and there is still a process with the read end open (even if that process is the one trying to write), then the write will hang, waiting for the reader to make space for the write to complete.

When I remove that line close(pipefd[1]); from the child’s process IF, I’m basically saying that “okay, the child can read from the pipe, but I’m allowing the parent to write to the pipe at the same time”?

No; you’re saying that the child can write to the pipe as well as the parent. Any process with the write file descriptor for the pipe can write to the pipe.

If so, what would happen when the pipe is open for both reading and writing — no mutual exclusion?

There isn’t any mutual exclusion ever. Any process with the pipe write descriptor open can write to the pipe at any time; the kernel ensures that two concurrent write operations are in fact serialized. Any process with the pipe read descriptor open can read from the pipe at any time; the kernel ensures that two concurrent read operations get different data bytes.

You make sure a pipe is used unidirectionally by ensuring that only one process has it open for writing and only one process has it open for reading. However, that is a programming decision. You could have N processes with the write end open and M processes with the read end open (and, perish the thought, there could be processes in common between the set of N and set of M processes), and they’d all be able to work surprisingly sanely. But you’d not readily be able to predict where a packet of data would be read after it was written.