INTER PROCESS COMMUNICATION

INTER PROCESS COMMUNICATION

Inter process Communication (IPC) refers to the methods and mechanisms that allow processes to communicate and coordinate with each other while executing concurrently within an operating system. IPC is essential for enabling processes to share data, synchronize actions, and manage resources effectively.

Relationships between processes in an operating system

Independent Process

A process is independent if it cannot affect or be affected by the other processes executing in the system. Any process that does not share data with any other process is independent.

Cooperative process

 A process is cooperating if it can affect or be affected by the other processes executing in the system. Clearly, any process that shares data with other  processes is a cooperating process.

There are several reasons for providing an environment that allows process cooperation:

 • Information sharing: Since several users may be interested in the same piece of information (for instance, a shared file), we must provide an environment to allow concurrent access to such information.

• Computation speedup: If we want a particular task to run faster, we must break it into subtasks, each of which will be executing in parallel with the others. Notice that such a speedup can be achieved only if the computer has multiple processing cores

. • Modularity: We may want to construct the system in a modular fashion, dividing the system functions into separate processes or threads

• Convenience: Even an individual user may work on many tasks at the same time. For instance, a user may be editing, listening to music, and compiling in parallel.

Related Articles

Key Aspects of Inter process Communication:

  1. Purpose:
    • IPC enables different processes to exchange information, send messages, and share resources, facilitating cooperation and coordination in multitasking environments.
  2. Types of IPC Mechanisms: Inter process communication can be implemented using various mechanisms, each with its own characteristics and use cases.
    • Here are some common Inter process communication mechanisms:
      • Pipes:
        • A pipe is a unidirectional communication channel that allows data to flow from one process to another. It is often used in command-line operations where the output of one command serves as the input for another.
      • Message Queues:
        • Message queues allow processes to send and receive messages in a structured way. They provide a way to store messages until the receiving process is ready to retrieve them.
      • Shared Memory:
        • Shared memory allows multiple processes to access a common memory space for fast data exchange. It is efficient but requires synchronization mechanisms to avoid data inconsistency.
      • Sockets:
        • Sockets enable communication between processes over a network. They are commonly used in client-server applications, allowing processes on different machines to communicate.
      • Signals:
        • Signals are a limited form of IPC used to notify processes of events, such as interrupts or exceptions. They can be used for simple communication and synchronization.
  3. Synchronization:
    • In many IPC scenarios, synchronization is necessary to ensure that processes do not interfere with each other when accessing shared resources. Common synchronization methods include locks, semaphores, and condition variables.
INTER PROCESS COMMUNICATION

How to choose right IPC method?

Choosing the right Inter process Communication (IPC) method depends on the specific requirements of the processes involved and the nature of their communication. Here’s a guide to help choose the appropriate IPC method:

1. Data Transfer Speed:

  • Use Shared Memory if you need very fast communication, as it allows direct access to data.
  • Avoid Message Queues for very high-speed requirements since they involve additional overhead in organizing and retrieving messages.

2. Communication Type (Unidirectional vs. Bidirectional):

  • Use Pipes for simple, unidirectional communication between parent-child processes.
  • Use Sockets if you need bidirectional communication, especially over a network.

3. Synchronization Needs:

  • Use Semaphores or Mutexes when processes need to coordinate access to shared resources.
  • Use Shared Memory with Semaphores if processes need both high-speed data sharing and controlled access.

4. Asynchronous vs. Synchronous Communication:

  • Use Message Queues for asynchronous communication where processes do not need to wait for each other.
  • Use Blocking Sockets for synchronous communication when processes need a coordinated exchange.

5. Network Communication:

  • Use Sockets if processes need to communicate across different systems over a network.
  • Avoid Shared Memory as it is typically limited to communication on the same machine.

6. Notification and Alerts:

  • Use Signals for simple, fast notifications, like interrupts or alerts, rather than complex data sharing.

Each IPC method has strengths suited to specific scenarios, so understanding the communication needs and system limitations will guide you in choosing the right one.

SYNCHRONIZATION in Operating System

Process synchronization in Operating system is the task of coordinating the execution of processes in such a way that no two processes can access the same shared data and resources. It is a critical part of operating system design, as it ensures that processes can safely share resources without interfering with each other.

Key Concepts of Synchronization

  1. Race Condition:
    • A race condition occurs when multiple processes or threads attempt to read and write shared data simultaneously, leading to unpredictable results. Synchronization mechanisms help prevent race conditions by ensuring that only one process can access the shared resource at a time.
  2. Critical Section:
    • A critical section is a segment of code that accesses shared resources and must not be concurrently executed by more than one process or thread. Proper synchronization is necessary to protect critical sections.
  3. Mutual Exclusion:
    • Mutual exclusion ensures that only one process or thread can access the critical section at any given time. This is a fundamental principle of synchronization.

Synchronization Mechanisms

  1. Locks:
    • Definition: Locks are used to enforce mutual exclusion by allowing only one process to enter the critical section at a time.
    • Types:
      • Mutexes: Binary locks that allow only one thread to access the critical section.
      • Spinlocks: Locks that keep checking (spinning) to acquire the lock until it becomes available.
  2. Semaphores:
    • Definition: Semaphores are signaling mechanisms that can control access to shared resources using a counter.
    • Types:
      • Counting Semaphores: Allow multiple processes to access a resource concurrently up to a specified limit.
      • Binary Semaphores: Similar to mutexes, they allow only one process to access the resource at a time.
  3. Monitors:
    • Definition: Monitors are high-level synchronization constructs that combine data encapsulation and synchronization. They automatically handle mutual exclusion and provide condition variables for signaling between threads.
    • Usage: Monitors simplify synchronization by encapsulating the critical section and associated data, allowing easier management of shared resources.
  4. Condition Variables:
    • Definition: Condition variables are used with locks to allow threads to wait for certain conditions to be met before proceeding.
    • Usage: A thread can wait on a condition variable when a certain condition is not met, and another thread can signal the condition variable when it changes, allowing the waiting thread to resume execution.
  5. Barriers:
    • Definition: Barriers are synchronization points that ensure all processes or threads reach a certain point before any can proceed.
    • Usage: Useful in parallel programming where multiple threads need to synchronize at specific stages.

Types of Inter Process Communication

Synchronous and Asynchronous communications are terms that describe how processes or threads interact with each other in terms of communication and timing. Here’s a simple explanation of both concepts:

Synchronous Communication

  • Definition: In synchronous communication, processes or threads operate in a coordinated manner, meaning one process waits for another to complete a task before it continues. Synchronous communication requires processes to wait for each other, making it more structured but potentially slower.
  • Characteristics:
    • Blocking Behavior: The sending or receiving process stops and waits until the other party completes the action.
    • Tightly Coupled: Processes are closely linked, and the timing of their operations is synchronized.
  • Example:
    • Imagine you are having a conversation with someone face-to-face. You both wait for each other to finish speaking before moving on to the next topic. If one person is silent, the other waits.

Asynchronous Communication

  • Definition: In asynchronous communication, processes or threads operate independently and do not need to wait for each other. They can continue executing without being blocked by the other process. Asynchronous communication allows processes to work independently, which can lead to increased efficiency and responsiveness, especially in systems with many concurrent operations
  • Characteristics:
    • Nonblocking Behavior: The sending or receiving process can send a message and continue with its tasks without waiting for the other process.
    • Loosely Coupled: Processes can function independently, allowing for more flexible and efficient interactions.
  • Example:
    • Think of sending an email. You write your message and send it without waiting for the recipient to read it. You can move on to other tasks while they read and respond at their convenience.

Message-Type passing in inter process communication

There are different options for implementing each primitive. Message-type passing in inter process communication may be either blocking or non blocking :

Blocking Send

  • What it Means: When a process wants to send a message, it stops (or “blocks”) and waits until the message has been received by the other process.
  • Simple Example: Imagine you are sending a letter to a friend. You wait at the mailbox until your friend comes to pick it up. You don’t leave until they have the letter.

2. Nonblocking Send

  • What it Means: When a process sends a message, it does so without waiting. It continues doing its work immediately after sending the message.
  • Simple Example: Think of texting a friend. You send the message and then continue with what you were doing, not waiting for them to respond.

3. Blocking Receive

  • What it Means: A process that wants to receive a message will stop and wait until a message is available to be received.
  • Simple Example: Imagine you are waiting for a friend to hand you a letter. You won’t do anything else until they give it to you.

4. Nonblocking Receive

  • What it Means: When a process tries to receive a message, it checks to see if there is one available. If there is, it takes it; if not, it continues running without waiting.
  • Simple Example: Picture checking your email. You look to see if there’s a new message. If there isn’t, you move on to another task without waiting.

BUFFERING in Operating System

Buffering in Operating system is the process of temporarily storing data in a memory area (called a buffer) while it is being transferred between two places, such as between a producer and a consumer in a queue.

The zero-capacity case is sometimes referred to as a message system with no buffering. The other cases are referred to as systems with automatic buffering. Basically, such queues can be implemented in three ways

  • Zero capacity: The queue has a maximum length of zero; thus, the link cannot have any messages waiting in it. In this case, the sender must block until the recipient receives the message. 
  • Bounded capacity: The queue has finite length n; thus, at most n messages can reside in it. If the queue is not full when a new message is sent, the message is placed in the queue (either the message is copied or a pointer to the message is kept), and the sender can continue execution without waiting. The link’s capacity is finite, however. If the link is full, the sender must block until space is available in the queue.
  •   Unbounded capacity: The queue’s length is potentially infinite; thus, any number of messages can wait in it. The sender never blocks.

PRODUCER AND CONSUMER PROBLEM

The Producer-Consumer problem (also known as the Bounded Buffer problem) is a classic synchronization problem in operating systems that illustrates the need for coordination between processes when they share a common resource. Here’s a breakdown of the problem:

Scenario

  • Producer: A process that generates data or items and adds them to a shared resource (like a buffer or queue).
  • Consumer: A process that takes data or items from the shared resource and uses or processes them.

The Producer and Consumer processes work asynchronously, meaning they operate at their own pace. However, they must share a finite buffer (storage) between them. The challenge arises in ensuring they don’t interfere with each other while accessing this shared buffer.

PRODUCER AND CONSUMER PROBLEM

Problem Constraints of Synchronization

  1. Limited Buffer Size: The buffer has a maximum capacity, so the producer must stop producing if the buffer is full, and wait until the consumer removes some items.
  2. Synchronization Requirement: The consumer should not try to consume an item if the buffer is empty, as there will be nothing to consume.
  3. Mutual Exclusion: Only one process should access the buffer at any given time to prevent data inconsistency.

Issues Without Synchronization

  • Data Corruption: If both producer and consumer modify the buffer simultaneously, data might be lost or corrupted.
  • Race Conditions: Multiple processes compete to modify shared data, leading to unpredictable outcomes.

Solution Using Synchronization Mechanisms

To solve the Producer-Consumer problem, various synchronization mechanisms are used, such as semaphores or mutex locks.

  1. Semaphores:
    1. Two semaphores are generally used: full and empty.
    1. full counts the number of items in the buffer that can be consumed.
    1. empty counts the available slots in the buffer for the producer to add new items.
    1. A mutex (binary semaphore) ensures that only one process accesses the buffer at a time.
  2. Mutex Lock:
    1. A mutex can lock the buffer so that only one process (either producer or consumer) can access it at any moment, preventing race conditions.

Example Workflow

  1. Producer checks if there’s an available slot (empty > 0). If so:
    1. It decrements empty, locks the buffer using the mutex, adds the item to the buffer, unlocks the mutex, and increments full to signal that there is one more item for consumption.
  2. Consumer checks if there’s an available item (full > 0). If so:
    1. It decrements full, locks the buffer using the mutex, removes an item from the buffer, unlocks the mutex, and increments empty to signal that there’s one more slot available for production.

Advantages of Solving Producer and Consumer Problem

  • Data Integrity: Ensures data consistency by preventing race conditions.
  • Efficient Resource Utilization: Prevents buffer overflow and underflow by controlling production and consumption rates.
  • Concurrency Control: Allows producer and consumer to operate concurrently without interfering with each other.

Pseudo Code of producer and consumer problem

Here’s the PSEUDO CODE of the Producer-Consumer problem using semaphores for synchronization.

// Initialize semaphores
semaphore mutex = 1;
semaphore full = 0;
semaphore empty = N; // N is the size of the buffer

// Producer process
procedure producer() {
    while (true) {
        wait(empty);          // Check if there’s space in the buffer
        wait(mutex);          // Lock access to the buffer
        addItemToBuffer();    // Produce an item (critical section)
        signal(mutex);        // Release the lock
        signal(full);         // Increase the count of full slots
    }
}

// Consumer process
procedure consumer() {
    while (true) {
        wait(full);           // Check if there are items to consume
        wait(mutex);          // Lock access to the buffer
        removeItemFromBuffer(); // Consume an item (critical section)
        signal(mutex);        // Release the lock
        signal(empty);        // Increase the count of empty slots
    }
}

Algorithm of // Initialize semaphores
semaphore mutex = 1;
semaphore full = 0;
semaphore empty = N; // N is the size of the buffer

// Producer process
procedure producer() {
while (true) {
wait(empty); // Check if there’s space in the buffer
wait(mutex); // Lock access to the buffer
addItemToBuffer(); // Produce an item (critical section)
signal(mutex); // Release the lock
signal(full); // Increase the count of full slots
}
}

Algorithm of producer and consumer problem

Here is a simple implementation of the Producer-Consumer problem in C using semaphores. This code demonstrates how the producer and consumer processes work with a fixed-size buffer while using semaphores for synchronization.

#include <stdio.h>
#include <pthread.h>
#include <semaphore.h>
#include <unistd.h>

#define BUFFER_SIZE 5 // Define the buffer size

int buffer[BUFFER_SIZE];
int in = 0; // Index for producer to add items
int out = 0; // Index for consumer to remove items

// Semaphores
sem_t empty;  // Counts empty slots in the buffer
sem_t full;   // Counts filled slots in the buffer
pthread_mutex_t mutex; // Ensures mutual exclusion

// Function for the producer
void *producer(void *param) {
    int item;
    while (1) {
        item = rand() % 100; // Produce a random item

        sem_wait(&empty); // Wait if there are no empty slots
        pthread_mutex_lock(&mutex); // Lock the buffer

        buffer[in] = item; // Add item to buffer
        printf("Producer produced: %d\n", item);
        in = (in + 1) % BUFFER_SIZE; // Move to the next slot

        pthread_mutex_unlock(&mutex); // Unlock the buffer
        sem_post(&full); // Signal that there is a new full slot

        sleep(1); // Simulate time taken to produce an item
    }
}

// Function for the consumer
void *consumer(void *param) {
    int item;
    while (1) {
        sem_wait(&full); // Wait if there are no full slots
        pthread_mutex_lock(&mutex); // Lock the buffer

        item = buffer[out]; // Remove item from buffer
        printf("Consumer consumed: %d\n", item);
        out = (out + 1) % BUFFER_SIZE; // Move to the next slot

        pthread_mutex_unlock(&mutex); // Unlock the buffer
        sem_post(&empty); // Signal that there is a new empty slot

        sleep(1); // Simulate time taken to consume an item
    }
}

int main() {
    pthread_t prod, cons;

    // Initialize the semaphores
    sem_init(&empty, 0, BUFFER_SIZE); // BUFFER_SIZE empty slots
    sem_init(&full, 0, 0); // No filled slots initially
    pthread_mutex_init(&mutex, NULL); // Initialize mutex

    // Create producer and consumer threads
    pthread_create(&prod, NULL, producer, NULL);
    pthread_create(&cons, NULL, consumer, NULL);

    // Wait for the threads to complete (they won’t in this infinite loop example)
    pthread_join(prod, NULL);
    pthread_join(cons, NULL);

    // Clean up (unreachable in this example but good practice)
    sem_destroy(&empty);
    sem_destroy(&full);
    pthread_mutex_destroy(&mutex);

    return 0;
}

Leave a comment