Scribd
Upload
11 views

Mutual Exclusion

Uploaded by

Juan Dela Cruz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
11 views

Mutual Exclusion

Uploaded by

Juan Dela Cruz
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 27

MUTUAL EXCLUSION

MUTUAL EXCLUSION

Mutual exclusion is a fundamental concept in concurrent


programming and operating systems, which ensures that only
one process or thread can access a critical section or shared
resource at a time. This is crucial to prevent conflicts,
inconsistencies, or race conditions when multiple processes or
threads attempt to modify shared data simultaneously.
KEY CONCEPTS OF MUTUAL EXCLUSION

1. Critical Section
2. Race Condition
CRITICAL SECTION

A part of a program where shared resources, like memory,


files, or variables, are accessed or modified.
Only one process or thread should be allowed in the critical
section at a time to avoid unexpected results.
RACE CONDITION

Occurs when the outcome of a program depends on the


sequence or timing of uncontrollable events, such as the
execution order of threads.
Mutual exclusion prevents race conditions by ensuring that
the critical section is accessed by only one entity at a time.
MUTUAL EXCLUSION MECHANISMS

Operating systems and programming languages provide various


synchronization mechanisms to achieve mutual exclusion. These
include:
1. Locks (Mutexes)
2. Semaphores
3. Monitors
4. Spinlocks
5. Atomic Operations
LOCKS (MUTEXES)

A mutex (mutual exclusion) lock is the simplest way to


enforce mutual exclusion.
When a thread or process wants to enter the critical section,
it acquires the lock. Other threads/processes must wait until
the lock is released.
After finishing in the critical section, the process releases
the lock, allowing another process to enter.
Example: pthread_mutex_lock() in POSIX threads.
SEMAPHORES:

Semaphores are signaling mechanisms used to control


access to shared resources.
A binary semaphore (or mutex semaphore) works like a lock,
allowing only one thread to access a critical section.
A counting semaphore can allow multiple processes to
access a resource but still enforce a limit on the number of
concurrent accesses.
BINARY SEMAPHORES

A binary semaphore is a synchronization mechanism that can


take only two values: 0 (locked) or 1 (unlocked). It is used to
control access to a critical section or a shared resource
where only one process or thread is allowed to enter at a
time. Binary semaphores function similarly to mutexes
(mutual exclusion locks) but are more general and can be
used for signaling as well.
BINARY SEMAPHORES

Key Features:
Values: 0 (resource is unavailable) or 1 (resource is
available).
Mutual exclusion: Ensures that only one thread or process
can access the critical section at a time.
Simpler to implement than counting semaphores because
they only track two states.
BINARY SEMAPHORES

Operations:
Wait (P operation): The process checks the semaphore value.
If it is 1, the process proceeds and sets the value to 0,
effectively "locking" the resource. If the value is 0, the
process waits.
Signal (V operation): When the process finishes, it sets the
semaphore value back to 1, "unlocking" the resource and
allowing another process to proceed.
BINARY SEMAPHORES

Example Scenario:
Suppose you have a printer shared by multiple processes. A
binary semaphore can be used to control access to the
printer:
When a process needs to print, it waits on the semaphore. If
the printer is free (semaphore value is 1), the process prints
and sets the semaphore to 0, preventing other processes
from printing.
After printing, the process signals the semaphore, setting it
back to 1, so the next process can print.
BINARY SEMAPHORES

Binary Semaphore Operations

sem_wait(&semaphore); // Wait (P operation) - Decrease the


semaphore value.
critical_section(); // Access the shared resource or critical
section.
sem_post(&semaphore); // Signal (V operation) - Increase the
semaphore value.
COUNTING SEMAPHORES

A counting semaphore is a more general form of semaphore that


can take any non-negative integer value. It is used to manage
access to a resource with multiple instances (e.g., multiple
identical printers or database connections). The value of a
counting semaphore represents the number of available
resources.
COUNTING SEMAPHORES

Key Features:
Values: Any non-negative integer, representing the number
of available resources.
Resource control: Used when there are multiple instances of
a resource and we want to allow a limited number of
processes to access them concurrently.
COUNTING SEMAPHORES

Operations:
Wait (P operation): The process checks the semaphore value.
If it is greater than 0, the process proceeds and decrements
the value by 1. If the value is 0, the process waits (indicating
no resources are available).
Signal (V operation): When the process finishes using the
resource, it increments the semaphore value by 1, signaling
that a resource has been released.
COUNTING SEMAPHORES

Example Scenario:
Consider a database connection pool with 5 connections:
Initially, the counting semaphore is initialized to 5, meaning
5 database connections are available.
When a process requests a connection, it waits on the
semaphore. If the semaphore value is greater than 0, the
process gets a connection, and the semaphore is
decremented. If all connections are in use (value = 0), the
process waits.
When a process finishes using a connection, it signals the
semaphore, incrementing the value and making the
connection available for another process.
COUNTING SEMAPHORES

Counting Semaphore Operations:

sem_wait(&semaphore); // Wait (P operation) - Decrease the


semaphore value.
critical_section(); // Access one instance of the shared
resource.
sem_post(&semaphore); // Signal (V operation) - Increase the
semaphore value.
COUNTING SEMAPHORES
COUNTING SEMAPHORES

Practical Uses:
Binary Semaphore: Used for protecting critical sections
where only one process or thread should enter, such as
writing to a file, accessing a printer, or modifying shared
memory.
Counting Semaphore: Used when multiple instances of a
resource are available, like managing a pool of database
connections, limiting the number of threads accessing a
network socket, or controlling the number of available seats
in a theater booking system.
MONITORS

A higher-level synchronization construct that combines


mutual exclusion and condition variables.
In a monitor, only one thread can execute a procedure at
any given time, and other threads wait until the monitor is
available.
SPINLOCKS

A type of lock where a process "spins" (i.e., continuously


checks) until the lock becomes available.
Useful in situations where the wait time is expected to be
short, but inefficient for long waiting times as it wastes CPU
cycles.
MUTUAL EXCLUSION REQUIREMENTS

To ensure safe and effective mutual exclusion, a solution


must satisfy the following properties:

Mutual Exclusion:
Only one process can be in the critical section at a time.
MUTUAL EXCLUSION REQUIREMENTS

Progress:
If no process is in the critical section, one of the processes
that wish to enter must be allowed to proceed.
The decision about which process enters the critical section
cannot be postponed indefinitely.
MUTUAL EXCLUSION REQUIREMENTS

Bounded Waiting (No Starvation):


There must be a limit on the number of times other processes
can enter the critical section before a waiting process is
granted access.
This prevents starvation, where a process waits indefinitely.
EXAMPLE OF MUTUAL EXCLUSION:

If two threads, A and B, are trying to increment a shared


variable:
Without mutual exclusion, both threads might read the same
value, increment it, and write the same incorrect result
(leading to a race condition).
With mutual exclusion (e.g., using a mutex), thread A will lock
the resource, increment the variable, release the lock, and
then thread B will do the same, ensuring the correct final
result.
IMPORTANCE OF MUTUAL EXCLUSION

Consistency: Ensures data consistency when multiple


threads/processes share resources.
Deadlock Prevention: Properly designed mutual exclusion
helps avoid deadlocks where processes are stuck waiting for
each other indefinitely.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy