Chapter 53: POSIX Semaphores

This chapter describes POSIX semaphores, which allow processes and threads to synchronize access to shared resources. In Chapter 47, we described System V semaphores, and we'll assume that the reader is familiar with the general semaphore concepts and rationale for using semaphores that were presented at the start of that chapter. During the course of this chapter, we'll make comparisons between POSIX semaphores and System V semaphores to clarify the ways in which these two semaphore APIs are the same and the ways in which they differ.

53 POSIX Semaphores
53.1 Overview
53.2 Named Semaphores
        53.2.1 Opening a Named Semaphore
        53.2.2 Closing a Semaphore
        53.2.3 Removing a Named Semaphore
53.3 Semaphore Operations
        53.3.1 Waiting on a Semaphore
        53.3.2 Posting a Semaphore
        53.3.3 Retrieving the Current Value of a Semaphore
53.4 Unnamed Semaphores
        53.4.1 Initializing an Unnamed Semaphore
        53.4.2 Destroying an Unnamed Semaphore
53.5 Comparisons with Other Synchronization Techniques
53.6 Semaphore Limits
53.7 Summary
53.8 Exercises

Chapter 52: POSIX Message Queues

This chapter describes POSIX message queues, which allow processes to exchange data in the form of messages. POSIX message queues are in several respects similar to System V message queues (Chapter 46), but there are also some notable differences, which we describe in this chapter.

52 POSIX Message Queues
52.1 Overview
52.2 Opening, Closing, and Unlinking a Message Queue
52.3 Relationship between Descriptors and Message Queues
52.4 Message Queue Attributes
52.5 Exchanging Messages
        52.5.1 Sending Messages: mq_send()
        52.5.2 Receiving Messages: mq_receive()
        52.5.3 Sending and Receiving Messages with a Timeout
52.6 Message Notification
        52.6.1 Receiving Notification Using a Signal (SIGEV_SIGNAL)
        52.6.2 Receiving Notification Using a Thread (SIGEV_THREAD)
52.7 Linux-specific Features
52.8 Message Queue Limits
52.9 Comparison of POSIX and System V Message Queues
52.10 Summary
52.11 Exercises

Chapter 51: Introduction to POSIX IPC

The POSIX.1b realtime extensions defined a set of IPC mechanisms that are analogous to the System V IPC mechanisms that we described in Chapters 45 to 48. (One of the POSIX.1b developers' aims was to devise a set of IPC mechanisms that did not suffer the deficiencies of the System V IPC facilities.) These IPC mechanisms are collectively referred to as POSIX IPC. The three POSIX IPC mechanisms are message queues, semaphores, and shared memory. This chapter provides an overview of the POSIX IPC facilities, focusing on the common features of the three POSIX IPC mechanisms.

51 Introduction to POSIX IPC
51.1 API Overview
51.2 Comparison of System V IPC and POSIX IPC
51.3 Summary

Chapters 56 to 61 are in copyedit

Chapter 55 cam back from copyedit. Chapters 56 to 61 have now gone off to the copyeditor.

Chapter 55 is in copyedit

Chapters 51 to 54 came back from copyedit. Chapter 55 is with the copyeditor.

Chapter 50: Virtual Memory Operations

This chapter looks at various system calls that perform operations on a process’s virtual address space:

• The mprotect() system call changes the protection on a region of virtual memory.
• The mlock() and mlockall() system calls lock a region of virtual memory into physical memory, thus preventing it from being swapped out.
• The mincore() system call allows a process to determine whether the pages in a region of virtual memory are resident in physical memory.
• The madvise() system call allows a process to advise the kernel about its future patterns of usage of a virtual memory region.

50 Virtual Memory Operations
50.1 Changing Memory Protection: mprotect()
50.2 Memory Locking: mlock() and mlockall()
50.3 Determining Memory Residence: mincore()
50.4 Advising Future Memory Usage Patterns: madvise()
50.5 Summary
50.6 Exercises

Chapter 49: Memory Mappings

This chapter discusses the use of the mmap() system call to create memory mappings. Among other topics, we consider four general uses of memory mappings:

• allocating process-private memory (private anonymous mappings);
• initializing the contents of the text and initialized data segments of a process (private file mappings);
• performing IPC by sharing sharing memory between processes related via fork() (shared anonymous mappings); and
• performing memory-mapped I/O, optionally combined with memory sharing (and thus IPC) between unrelated processes (shared file mappings).

49 Memory Mappings
49.1 Overview
49.2 Creating a Mapping: mmap()
49.3 Unmapping a Mapped Region: munmap()
49.4 File Mappings
      49.4.1 Private (MAP_PRIVATE) File Mappings
      49.4.2 Shared (MAP_SHARED) File Mappings
      49.4.3 Boundary Cases
      49.4.4 Memory Protection and File Access Mode Interactions
49.5 Synchronizing a Mapped Region: msync()
49.6 Additional mmap() Flags
49.7 Anonymous Mappings
49.8 Remapping a Mapped Region: mremap()
49.9 The MAP_NORESERVE Flag and Swap Space Overcommitting
49.10 The MAP_FIXED Flag
49.11 Nonlinear Mappings: remap_file_pages()
49.12 Summary
49.13 Exercises

Chapter 48: System V Shared Memory

This chapter describes System V shared memory. Shared memory allows two or more processes to share the same region (usually referred to as a segment) of physical memory. Since a shared memory segment becomes part of a process's user-space memory, no kernel intervention is required for IPC. All that is required is that one process copies data into the shared memory; that data is immediately available to all other processes sharing the same segment. This provides fast IPC by comparison with techniques such as pipes or message queues, where the sending process copies data from a buffer in user space into kernel memory and the receiving process copies in the reverse direction. (Each process also incurs the overhead of a system call to perform the copy operation.)

On the other hand, the fact that IPC using shared memory is not mediated by the kernel means that, typically, some method of synchronization is required so that processes don’t simultaneously access the shared memory (e.g., two processes performing simultaneous updates, or one process fetching data from the shared memory while another process is in the middle of updating it). System V semaphores are a natural method for synchronizing access to System V shared memory segments

48 System V Shared Memory
48.1 Overview
48.2 Creating or Opening a Shared Memory Segment: shmget()
48.3 Using Shared Memory: shmat() and shmdt()
48.4 Example: Transferring Data Via Shared Memory
48.5 Location of Shared Memory Segments in Virtual Memory
48.6 Storing Pointers in Shared Memory
48.7 Shared Memory Control Operations: shmctl()
48.8 Shared Memory Associated Data Structure
48.9 Shared Memory Limits
48.10 Summary
48.11 Exercises

Chapter 47: System V Semaphores

This chapter describes System V semaphores. Unlike the IPC mechanisms described in previous chapters, System V semaphores are not used to transfer data between processes. Instead, they allow processes to synchronize their actions. One common use of a semaphore is to synchronize access to a block of shared memory, in order to prevent one process from accessing the shared memory at the same time as another process is updating it.

47 System V Semaphores
47.1 Overview
47.2 Creating or Opening a Semaphore Set: semget()
47.3 Semaphore Control Operations: semctl()
47.4 Semaphore Associated Data Structure
47.5 Semaphore Initialization
47.6 Semaphore Operations: semop()
47.7 Handling of Multiple Blocked Semaphore Operations
47.8 Semaphore Undo Values
47.9 Implementing a Binary Semaphores Protocol
47.10 Semaphore Limits
47.11 Disadvantages of System V Semaphores
47.12 Summary
47.13 Exercises

Chapters 51 to 54 are in copyedit

Chapters 49 and 50 came back from copyedit. Chapters 51 to 54 have gone to the copyeditor.

Chapter 46: System V Message Queues

This chapter describes System V message queues. Message queues allow processes to exchange data in the form of messages. Message queues are somewhat like pipes, but differ in two important respects. First, message boundaries are preserved, so that readers and writers communicate in units of messages, rather than via an undelimited byte stream. Second, each message includes an integer type field, and it is possible to select messages by type, rather than reading them in the order in which they were written.

46 System V Message Queues
46.1 Creating or Opening a Message Queue: msgget()
46.2 Exchanging Messages
46.2.1 Sending Messages: msgsnd()
46.2.2 Receiving Messages: msgrcv()
46.3 Message Queue Control Operations: msgctl()
46.4 Message Queue Associated Data Structure
46.5 Message Queue Limits
46.6 Displaying All Message Queues on the System
46.7 Client-server Programming with Message Queues
46.8 A File-server Application Using Message Queues
46.9 Disadvantages of System V Message Queues
46.10 Summary
46.11 Exercises

Chapter 45: Introduction to System V IPC

System V IPC is the label used to refer to three different mechanisms for interprocess communication: message queues, semaphores, and shared memory.

Although these three forms of IPC are quite diverse in function, there are good reasons for discussing them together. One reason is that these mechanisms were developed together, and originally made their way into mainstream Unix by appearing in System V--hence the appellation System V IPC. A more significant reason for discussing the System V IPC mechanisms together is that their programming interfaces share a number of common characteristics, so that many of the same concepts apply to all of these mechanisms.

This chapter provides an overview of the System V IPC mechanisms and details those features that are common to all three mechanisms. The three mechanisms are then discussed individually in the following chapters.

45 Introduction to System V IPC
45.1 API Overview
45.2 IPC Keys
45.3 Associated Data Structure and Object Permissions
45.4 IPC Identifiers and Client-server Applications
45.5 Algorithm Employed by System V IPC get Calls
45.6 The ipcs and ipcrm Commands
45.7 Obtaining a List of All IPC Objects
45.8 IPC Limits
45.9 Summary
45.10 Exercises

Chapter 44: Pipes and FIFOs

This chapter describes pipes and FIFOs. Pipes are the oldest method of IPC on the Unix system, having appeared in Third Edition Unix in the early 1970s. Pipes provide an elegant solution to a frequent requirement: Having created two processes to run different programs (commands), how can the shell allow the output produced by one process to be used as the input to the other process? Pipes can be used to pass data between related processes. FIFOs are a variation on the pipe concept. The important difference is that FIFOs can be used for communication between any processes.

44 Pipes and FIFOs
44.1 Overview
44.2 Creating and Using Pipes
44.3 Pipes As a Method of Process Synchronization
44.4 Using Pipes to Connect Filters
44.5 Talking to a Shell Command via a Pipe: popen() and pclose()
44.6 Pipes and stdio Buffering
44.7 FIFOs
44.8 A Client-server Application Using FIFOs
44.9 Nonblocking I/O
44.10 Semantics of read() and write() on Pipes and FIFOs
44.11 Summary
44.12 Exercises

Chapter 43: Interprocess Communication Overview

This chapter presents a brief overview of the facilities that processes and threads can use to communicate with one another and to synchronize their actions. The following chapters provide more details about these facilities.

43 Interprocess Communication Overview
43.1 A Taxonomy of IPC Facilities
43.2 Communication Facilities
43.3 Synchronization Facilities
43.4 Comparing IPC Facilities
43.5 Summary
43.6 Exercises

We have a book title!

A few weeks ago, I posted some candidate titles for my book, and asked for feedback from readers about what title(s) they thought worked. I also pinged many of my technical reviewers to ask them for their thoughts on the titles in the blog post.

The candidate titles were:

1. Linux System and Network Programming
2. Linux/UNIX System and Network Programming
3. Linux and UNIX System Programming
4. The Craft of Linux Programming
5. Advanced Programming in the Linux Environment
6. Something else?

This is what happened.

1. Linux System and Network Programming

This was my original working title, conceived in a time when I planned to write a smaller book in which the network programming component would be a substantial portion of the book.

This title got almost no votes, and a number of negative responses from my tech reviewers. Those responses were generally along the lines: "networking is an important part of the book, but just a small part of a book that covers many APIs". This was exactly the reason why I had already decided that I didn't much like this title, and the feedback was enough to confirm to me that this was not the right title.

2. Linux/UNIX System and Network Programming

This scored only negative votes, which was no surprise to me (I only included it for the purposes of shoehorning "UNIX" into the previous title, to see if that got any positive response).

Two down.

3. Linux and UNIX System Programming

This title got several solid votes from a few people, including a few of my key reviewers, and no one had strong reservations.

The virtue of this title is its simplicity, and that it captures key points: Linux, UNIX (and thus portability), and system programming.

Some people agreed with me that this title is solid.

And some agreed that it's a little bland; the title lacks distinction. As Bill O. Gallmeister wrote:

The problem with many of the Linux programming book titles, in my opinion, is they run together. I guess that's just because there are a lot of them. Some combination of the words Linux, System, Programming, Network, Kernel, Advanced...

And you could substitute the word "UNIX" for "Linux" in the above paragraph, and the argument would also hold. (There already exist several books that use "UNIX System Programming" in their titles.)

The conservative in me said: solid is good; bland is not fatal. However, when I factored in the crowded namespace, I was left with the feeling that while I could live with this title, I was not really convinced by it.

Two down, one left standing (just).

4. The Craft of Linux Programming

Titles 4 and 5 got the most votes. Among other things, this said to me that many people are interested primarily in Linux, and don't need to see UNIX in the title.

I concluded that one reason why people like title 4 is that it is distinctive. (This was one reason that title 4 was for a long time my favorite.) Title 4 also got several responses along the lines that the title was "soft" and "vague" ("I'm not quite sure from this title what your book is about"). I take their point. This is a significant weakness of the title. And in the end, I decided the weakness was fatal.

Three down, one left standing (just).

5. Advanced Programming in the Linux Environment

This title kept surprising me with its level of positive response. It got about as many positive votes as title 4.

I take the strong positive vote for this title as meaning this:

• From my tech reviewers: a strong vote of confidence in the quality of what they have read.
• From others (and perhaps some technical reviewers as well): a desire to see a book that is near the quality of Advanced Programming in the UNIX Environment (a quality sustained by Steve Rago in the second edition), but focused on Linux.

But after considering it at length (and noting the doubts expressed by a few people), I decided I just couldn't go with this title, for the following reasons:

• The titles APLE and APUE would just be too close. Some people will get confused by the closeness. (One person noted that this might be to my benefit!)
• The title suggests my book is a clone of APUE, which isn't accurate. I cover many subjects that aren't in APUE and give special focus to a particular UNIX implementation.
• While I like the notion of acknowledging the brilliance of Rich Stevens book(s) with a play on his title, in the end, the closeness of the titles was just too great for me to feel comfortable.

So, I was left with four titles down, and one left standing. But, as I explained above, it is hard for me to love the title Linux and UNIX System Programming.

6. Something else?

This is the virtue of the FOSS approach: use other people's good ideas.

In among several lengthy mails I got, there was one from a friend and former colleague, Alejandro Forero Cuervo. Alejo offered some short and incisive criticisms of my five candidate titles, and then did a nice analysis to come up with an alternative:

You want to convey very briefly what your book is about. In a few words I would say the book is about the abstractions provided in Linux, and to some extent other UNIX systems, that one needs to know to effectively develop applications (daemons, command line tools, networking clients, etc.). I think the word "Programming" very appropriately conveys part of that (rather than things like "Software development" or such). Also, something remarkable about your book is, I think, that it provides very complete coverage of the topics it touches on. That is, your book isn't just a short leaflet on where to look for what, but rather provides *everything* one should need to know.

Programming in Linux. Is this title taken? I quite like it. It emphasizes the scope of your book: you're publishing the best book for how to program in Linux so far. The title has the beauty of being simple and acknowledges that your book will be, probably for a long time (if not ever) the best book about how to program in Linux. A variation of this could be Linux Programming.

The Linux Programming Interface. This very precisely matches the topic of the book, right? I think it very briefly conveys entirely what the book is about. Of all the titles, this would probably be the one I'd choose.

It took me a day or so of reflection, but then I decided that I really liked The Linux Programming Interface as a title:

• It's short and elegant.
• It's distinctive.
• As Alejo noted, it succinctly captures the essence of the book.

The word Interface is perfect: it precisely identifies the area in which I've been working for years. Later, I looked at my draft preface (extract here), and saw that I used the word interface four times in the first four sentences! (Alejo really channeled something when he came up with this title idea.)

But, there seemed to be some downsides to this title:

• It doesn't mention UNIX.
• It doesn't mention System Programming, which is a term some people might search on.

I thought about this lack of UNIX in the title quite a bit.

There is for me a positive aspect in focusing on just Linux in the title: it is because of Linux (a free UNIX) that I am writing this book, and indeed it may even be because of Linux that I'm still in computing. And then, Linux is becoming by a margin the most popular UNIX. Focusing on Linux in the title is an acknowledgement of these facts.

On the other hand, UNIX is what got us here (and where I started learning), and I do like history and acknowledging origins. And of course, my book devotes quite a lot of space to portability across contemporary UNIX implementations.

I decided that UNIX must be kept somehow, but the way to do this was is in a subtitle.

The lack of the word System in the title also bothered me, since the term System Programming is commonly applied to programming with the interfaces that this book is about. So, I leaned toward an alternative title: The Linux System Programming Interface. I reasoned that this was nearly as short and elegant as the other title, was still somewhat distinctive, and was a helpful indicator for those people who might not be sure which interface was being referred to.

I asked a few people who had sent more detailed responses on the other titles for their thoughts about these two new titles. The response was generally very positive, but there was no clear winner between the two versions.

As I reflected on this further, I began to wonder whether adding System to the title did indeed detract too much from its simplicity and elegance. (Alejo was quite certain that the word System was not needed.) And so I began to lean back towards Alejo's initial proposal, and consider whether we could preserve the words System Programming in the subtitle. What finally confirmed things for me was the belief of my publisher, Bill Pollock, that the shorter title is better.

So there we have it: The Linux Programming Interface, with a subtitle that will include the terms UNIX and System Programming.

Updated, 2009-10-08: fixed an incorrect hyperlink

Chapters 49 and 50 are in copyedit

Chapters 45 to 48 already went to the copyeditor, and came back. Now, chapters 49 and 50 are in copyedit.