Notes/Operating Systems/Inter-Process Communication.md

type, backlinks

type	backlinks
theoretical	Overview#Multiprogramming

Intro

Processes frequently need to communicate with other processes.

Independent

Cannot affect or be affected by other processes.

Dependent

The opposite

Why?

• Information sharing
• Computation speedup
• Modularity
• Convenience

Methods

Shared memory

block-beta
  columns 1
	a["Process A"] Shared b["Process B"] ... Kernel

Processes/threads exchange information by writing in shared memory variables. This is where Concurrency becomes an issue.

Synchronization

To remedy the race condition issue, we should synchronize shared memory access. In other words, when a process writes to shared memory, others mustn't be able to. Multiple read access is allowed though.

Message passing (queueing)

block-beta
  columns 1
	a["Process A"] b["Process B"] ... ... Kernel

Processes communicate with each other by exchanging messages. A process may send information to a port, from which another process may receive information. We need to at least be able to send() and receive().

Concurrency

Accessing the same shared memory might at the same time will cause issues. This occurrence is called a Race Condition.

[!IMPORTANT]- When does it occur? A race condition occurs when some processes or threads can access (read or write) a shared data variable concurrently and at least one of the accesses is a write access (data manipulation).

The result depends on when context switching¹ happens.

The part of the program where shared memory is accessed is called the Critical Section (CS).

Critical Regions/Sections

Avoiding race conditions

[!IMPORTANT]- Conditions

1. No two processes may be simultaneously inside their critical regions. (Mutual Exclusion)
2. No assumptions may be made about speeds or the number of CPUs.
3. No process running outside its critical region may block other processes.
4. No process should have to wait forever to enter its critical region. (Starvation)

Locks

A flag which tells us whether the shared memory is currently being written into.

Mutexes

Mutual exclusion - a type of lock, specifically to enforce point 1 in Avoiding race conditions (i.e. enforcing mutual exclusion).

Semaphores

Can alllow more than one thread to access a resource. Based on amount of permits. Could be a binary one, which is essentially just a lock, otherwise is called a counting semaphore, only allowing as much writes as implemented.

Use a wait()

void wait(int *S){  
	while((*S)<=0);   // busy waiting  
	(*S)--;  
}

and a signal():

void signal(int *S){  
	(*S)++;  
}

Just keep a fucking list of processes currently semaphoring.

Producer-Consumer Problem

• The producer produces items and places them in the buffer.
• The consumer removes items from the buffer for processing We need to ensure that when a producer is placing an item in the buffer, then at the same time consumer should not consume any item. In this problem, the buffer is the critical section.

[!example]- How do we solve this? To solve this problem, we need two counting semaphores – Full and Empty. “Full” keeps track of some items in the buffer at any given time and “Empty” keeps track of many unoccupied slots.

Readers-Writers Problem

• Multiple readers can access the shared data simultaneously without causing any issues because they are only reading and not modifying the data.
• Only one writer can access the shared data at a time to ensure data integrity

We already mentioned this inSynchronization

[!example]- How do we solve this? Two solutions. We either give priority to readers or writers, but we have to do so consistently. This means that we let read/write happen first until exhaustion.

Peterson's Algorithm

Where i and j are separate processes.

1. Two Boolean flags: one for each process (e.g.,flag[0] and flag[1]). Each flag indicates whether the corresponding process wants to enter the critical section.

flag[i] = true;
turn = j;
while (flag[j] && turn == j) {
    // busy wait[^2]
}

3. Once the while loop condition fails, process i enters its critical section.
4. After finishing its critical section, process i sets flag[i] to false.
5. Repeat!

Monitors

A high-level abstraction that provides a convenient and effective mechanism for process synchronization. It defines procedures (i.e. methods).

Warning

Only one process may be executing any of the monitor's procedures at a time within the monitor at a time

It uses condition variables (often with wait and signal²operations) to allow threads to wait for certain conditions to be met before proceeding.

---

---

1. Context switching ↩︎

2. to the other threads ↩︎