Page 284 - DCAP403_Operating System

Unit 13: Case Study: Linux

receive signals and it will be woken by the reader when there is enough room for the write data Notes
or when the pipe is unlocked. When the data has been written, the pipe’s VFS inode is unlocked
and any waiting readers sleeping on the inode’s wait queue will themselves be woken up.
Reading data from the pipe is a very similar process to writing to it.

Processes are allowed to do non-blocking reads (it depends on the mode in which they opened

the file or pipe) and, in this case, if there is no data to be read or if the pipe is locked, an error will
be returned. This means that the process can continue to run. The alternative is to wait on the
pipe inode’s wait queue until the write process has finished. When both processes have fi nished

with the pipe, the pipe inode is discarded along with the shared data page.
Linux also supports named pipes, also known as FIFOs because pipes operate on a First In, First
Out principle. The first data written into the pipe is the first data read from the pipe. Unlike

pipes, FIFOs are not temporary objects, they are entities in the file system and can be created

using the mkfifo command. Processes are free to use a FIFO so long as they have appropriate

access rights to it. The way that FIFOs are opened is a little different from pipes. A pipe (its two
file data structures, its VFS inode and the shared data page) is created in one go whereas a FIFO

already exists and is opened and closed by its users. Linux must handle readers opening the FIFO
before writers open it as well as readers reading before any writers have written to it. That aside,
FIFOs are handled almost exactly the same way as pipes and they use the same data structures
and operations.
13.8.3 System V IPC Mechanisms

Linux supports three types of interprocess communication mechanisms that first appeared in
Unix TM System V (1983). These are message queues, semaphores and shared memory. These
System V IPC mechanisms all share common authentication methods. Processes may access
these resources only by passing a unique reference identifier to the kernel via system calls. Access

to these System V IPC objects is checked using access permissions, much like accesses to fi les
are checked. The access rights to the System V IPC object is set by the creator of the object via
system calls. The object’s reference identifier is used by each mechanism as an index into a table

of resources. It is not a straight forward index but requires some manipulation to generate the
index.
All Linux data structures representing System V IPC objects in the system include an ipc_perm
structure which contains the owner and creator process’s user and group identifiers. The access

mode for this object (owner, group and other) and the IPC object’s key. The key is used as a way

of locating the System V IPC object’s reference identifier. Two sets of keys are supported: public
and private. If the key is public then any process in the system, subject to rights checking, can fi nd
the reference identifier for the System V IPC object. System V IPC objects can never be referenced

with a key, only by their reference identifi er.

13.8.4 Message Queues

Message queues allow one or more processes to write messages, which will be read by one or
more reading processes. Linux maintains a list of message queues, the msgque vector; each
element of which points to a msqid_ds data structure that fully describes the message queue.
When message queues arxe created a new msqid_ds data structure is allocated from system
memory and inserted into the vector.

LOVELY PROFESSIONAL UNIVERSITY 277