Process Concept – V

Continuing from the previous post, we discuss three different IPC systems in this post : POSIX API for shared memory, Message passing in Mach and Shared memory as a mechanism for message passing in Windows.

POSIX Shared Memory

Before discussing the shared memory mechanism for inter-process communication in POSIX, let us briefly know what exactly POSIX is.

POSIX stands for Portable Operating System Interface, which is a set of standard operating system interfaces based on the UNIX operating system. You can read more about POSIX here.

  • POSIX has IPC mechanisms which use shared memory system as well as message passing system. Here, we discuss the shared memory system.
  • POSIX shared memory :
    • organized using memory-mapped files
    • i.e. , associate region of shared memory with a file
  • Step 1 → Creation of shared memory object
    • Cooperating process creates a shared memory object through the shm_open() system call.

  • name → name of shared memory object [Processes use this name to access shared memory]
  • O_CREAT | O_RDRW → parameters, specify that 
    • shared memory object is to be created, if it doesn’t exist
    • object is to be open for reading and writing
  • 0666 → parameter, establish directory permissions for shared object
  • shm_fd → successful call to shm_open() return integer file descriptor for the shared-memory object 
  • Step 2 → Configure size of object
    • After object created successfully, configure the size of object
  • here, ftruncate function sets the size of object to 4096 bytes.
  • Step 3 → Establish memory-mapped file
    • mmap() function → used to establish a memory-mapped file containing shared-memory object.
  • mmap() return a pointer to the memory-mapped file
  • this pointer is used to access the shared-memory object
  • MAP_SHARED → flag to specify that the changes to shared-memory object will be visible to all processes sharing the object.


MACH Message Passing

 Mach is a kernel developed to support OS research, primarily distributed and parallel computing. Read more about it here.

  • Mach supports creation and destruction of multiple tasks [similar to processes, but have multiple threads of control, and fewer associated resources]
  • Mach kernel provides message-oriented, capability-based inter-process communication → Communication in Mach (inter-task information) is carried out by Messages.
  • IPC primitives in mach operate on 3 abstractions
    • messages
    • ports
    • port sets
  • Ports → Ports are mailboxes used to send and receive messages in Mach
  • The system calls in mach are made by messages.
    • Task created → Kernel mailbox and Notify mailbox created.
    • Kernel mailbox → used by kernel to communicate with task and send notification of even occurrences to notify port.
    • 3 systems calls needed for message transfer
      • msg_send() → send message to mailbox
      • msg_receive() → receive a message
      • msg_rpc() → used to execute Remote procedure calls (RPCs : will be discussed later).
        • Sends a message and waits for exactly one return message from sender.
        • RPC models a typical subroutine call, but can work between systems → hence remote.

Message Passing system

  • Step 1 → Creation of Mailboxes
    • port_allocate() system call is used to create a new mailbox and allocates space for its queue of messages. 
    • default maximum size of message queue → 8 messages
    • Owner of a mailbox is the task that creates the mailbox
    • Owner → is allowed to receive from the mailbox.
    • Only one task at a time can either own or receive from a mailbox, but these rights can be sent to other tasks.
  • Step 2Sending and Receiving messages
    • Message queue is initially empty.
    • Messages which are sent to mailbox are copied to the mailbox.
    • all messages have same priority. Multiple messages from same sender are queued in FIFO order.
    • But there is no guarantee for absolute ordering → messages from 2 senders may be queued in any order.
    • Message composition
      • fixed-length header
        • indicates length of message
        • includes two mailboxes name
          • one to specify the mailbox to which message is being sent
          • Since the sending thread expects a reply, mailbox name of the sender is passes on the receiving task, which can use it as return address.
      • variable-length data portion : list of typed data items
        • each entry in the list has a type,size,value
        • type of data item important → since objects defined by the operating system—such as ownership or receive access rights, task states, and memory segments—may be sent in messages.
    • Sending message : flexible operation. Two cases can happen.
      • Message sent to mailbox which is not full
        • message is copied to mailbox
        • sending thread continues
      • Message sent to mailbox which is full → Sending thread has 4 options
        • Wait indefinitely until there is room in the mailbox.
        • Wait at most n milliseconds.
        • Do not wait at all but rather return immediately.
        • Temporarily cache the message.
          • Here, OS is asked to keep the message, even though the mailbox is full
          • When space becomes available in the mailbox, the message is copied there, and a message is sent back to the sender.
          • Only 1 message can be kept pending at any given time for a full mailbox.
          • This operation is meant for server tasks, such as line-printer driver. After finishing a request, such tasks may need to send a one-time reply to the task that requested service, but they must also continue with other service requests, even if the reply mailbox for a client is full.
    • Receiving message : 
      • Receive operation must specify the mailbox or mailbox set from which a message is to be received.
        • Why? Because threads in a task can receive only from one mailbox or mailbox set for which the task has receive access. 
      • Mailbox set : collection of mailboxes, as declared by the task, which can be grouped together, and treated as one mailbox for the purposes of the task.
      • port_status() : system call to know the number of messages in a given mailbox.
      • receive operation attempts to receive from
        • any mailbox in a mailbox set or
        • a specific (named) mailbox.
      • If no message is waiting to be received, the receiving thread can either wait at most n milliseconds or not wait at all.
  • Problem with message systems
    • double copying of messages → first from sender to mailbox and then from mailbox to receiver
    • To avoid this, Mach uses virtual memory-management techniques
      • Mach maps the address space containing sender’s message to receiver’s address space.
      • Message itself is never copied. → gives a large performance boost
      • However, works only for intrasystem messages.

Windows Message Passing : Advanced Local Procedure Call

  • Windows OS message passing → example of modern design 
  • uses modularity to increase functionality and decrease the time needed to implement new features.
  • provides support for multiple OS environments, or subsystems
    • application programs considered clients of subsystem server
    • Application programs can communicate with these subsystems via message-passing mechanism

Advanced local procedure call 

  • message passing facility in Windows 
  • used for communication between two processes on the same machine
  • similar to standard RPC mechanism, but optimized for windows. [RPC stands for remote procedure calls : Remote Procedure Call (RPC) is a protocol that one program can use to request a service from a program located in another computer on a network without having to understand the network’s details We will discuss this in detail in the next post.]
  • Step 1 → Creation of ALPC channel
    • Windows uses two types of ports : Connection ports and communication ports
    • First, Server processes publish connection-port objects that are visible to all processes
    • When a client wants services from a subsystem, it opens a handle to the server’s connection-port object and sends a connection request to that port.
    • The server then creates a channel and returns a handle to the client.
    • ALPC channel
      • consists of a pair of private communication ports:
        • one for client—server messages,
        • the other for server—client messages
      • supports a callback mechanism that allows the client and server to accept requests when they would normally be expecting a reply
  • Step 2 → Choosing a message passing technique
    • For small messages (up to 256 bytes)
      • the port’s message queue is used as intermediate storage, and the messages are copied from one process to the other.
    • Larger messages
      • these must be passed through a section object, which is a region of shared memory associated with the channel.
    • Huge amount of data
      • When the amount of data is too large to fit into a section object, an API is available that allows server processes to read and write directly into the address space of a client.
    • If client needs to send data, it chooses its own message passing technique. Similarly, the server chooses its own message passing technique for replies appropriately.
Advanced local procedure calls in Windows.
Advanced local procedure calls in Windows.


  • ALPC facility is not a part of Windows API → not visible to Application programmer.
  • Applications using the Windows API invoke standard remote procedure calls.
  • When the RPC is being invoked on a process on the same system, the RPC is handled indirectly through an ALPC procedure call.
  • Additionally, many kernel services use ALPC to communicate with client processes.

In the next post, we will discuss three more IPC mechanisms : Sockets, RPC and Pipes. Until then, keep reading and sharing 🙂