0% found this document useful (0 votes)
9 views

Process Synchronization Reviewer 065012

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
0% found this document useful (0 votes)
9 views

Process Synchronization Reviewer 065012

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/ 4

PROCESS SYNCHRONIZATION REVIEWER

Cooperating Process:
o Processes that can affect or be affected by other processes executing in the system.
o Cooperating process can either:
1) Directly share a logical address space (both code and data)
2) Be allowed to share data only through files or messages
o Concurrent access to shared data may result in data inconsistency, that’s why we need various
mechanisms to ensure the orderly execution of cooperating processes that share a logical
address space.

Race Condition
o A situation where several processes access and manipulate the same data concurrently and the
outcome of the execution depends on the particular order in which the access takes place.
o To avoid such conditions that most likely will lead to inaccurate answers, we need to ensure
that only one process at a time can change or modify the data.
o Thus, we require processes to be synchronized in some way.

Critical Section
o A segment of code in which the process may be changing common variables, updating a table,
writing a file, etc.
o When one process is executing in its critical section, no other process is allowed to execute in
its critical section.
o There should be no two processes that are executing in their critical sections at the same time.

General Structure of a Typical Process


o Entry section
o Critical section
o Exit section
o Remainder section

3 Requirements to Resolve the Critical-Section Problem


o Mutual Exclusion: When one process is executing in its critical section, then no other
processes can be executing in their critical sections
o Progress: If no process is executing in its critical section and some processes wish to enter
their critical sections, then only those processes that are not executing in their remainder
sections can participate in deciding which will enter its critical section next, and this selection
cannot be postponed indefinitely.
o Bounded Waiting: There exist a bound, or limit, on the number of times that other processes
are allowed to enter their critical sections after a process has made a request to enter its critical
section and before that request is granted.

Chapter II: Synchronization Mechanism

Software Based Solution to Critical-Section Problem


Peterson’s Solution
o A classic software- based solution to the critical-section problem
o However, it may not work correctly on modern computer architectures because of the way
modern computer architectures perform basic machine-language instructions, such as load and
store.
o Despite of its limited functionality, Peterson’s solution provides a good algorithmic description
of solving the critical-section problem and illustrates some of the complexities involved in
designing software that addresses the requirements of mutual exclusion, progress, and bounded
waiting requirement.
o Peterson’s solution is restricted to two processes that alternate execution between their critical
sections and remainder sections.
o This solution requires two data items to be shared between the two processes:
1) int turn: Indicates whose turn it is to enter its critical section
2) bool flag: Indicate if a process is ready to enter its critical section

Mutex Locks
o Mutex locks protect critical regions and prevent race conditions.
o A process must acquire the lock before entering a critical section and release the lock when it
exits the critical section.
o One of the disadvantages of mutex locks is that it requires busy waiting.
o Busy waiting wastes CPU cycles that some other processes might be able to use
productively, which makes mutex locks a problem in multiprogramming systems.
o Since while a process is still in its critical section, any other process that tries to enter
its critical section must loop continuously in the call to acquire().
o In fact, mutex lock is also called spinlock because the process “spins” while waiting
for the lock to become available.
Hardware Based Solution to Critical-Section Problem
Test and Set Lock
o There is a shared lock variable which can take either of the two values, 0 or 1.
o Before entering into the critical section, a process inquires about the lock.
➢ It is locked, it keeps on waiting until it becomes free.
➢ If it is not locked, it takes the lock and executes the critical section.

Semaphores
o Semaphores was proposed by Edsger Dijkstra, it is a technique to manage concurrent processes
by using a single integer value, which is known as semaphore.
o Semaphore is simply a variable which is non-negative and shared between threads. This
variable is used to solve the critical section problem and to achieve process synchronization in
the multiprocessing environment.
o A semaphore S is an integer variable that, apart from initialization is accessed only through 2
standard atomic operations: wait() and signal().
o All the modifications to the integer value of the semaphore in the wait() and signal() operations
must be executed indivisibly.
o That is, when one process modifies the semaphore value, no other process can simultaneously
modify that same semaphore value.

Types of Semaphores
1) Binary Semaphore
o The value of a binary semaphore can range only between 0 and 1.
o On some systems, binary semaphores are known as mutex locks, as they are locks that
provides mutual exclusion.
2) Counting Semaphores
o Its value can range over an unrestricted domain.
o It is used to control access to a resource that has multiple instances

CHAPTER II: CLASSIC PROBLEMS OF SYNCHRONIZATION

The Bounded Buffer Problem


o The Bounded Buffer Problem (Producer Consumer Problem), is one of the classic problems
of synchronization.
o There is a buffer of n slots and each slot is capable of storing one unit of data.
o There are two processes running, namely, Producer and Consumer, which are operating in the
buffer.
1) The producer tries to insert data into an empty slot of the buffer.
2) The consumer tries to remove data from a filled slot in the buffer.

The Readers-Writers Problem


o A database is to be shared among several concurrent processes.
o Some of these processes may want only to read the database, whereas others may want to
update (that is, to read and write) the database.
o We distinguish between these two types of processes by referring to the former as Readers and
to the latter as Writers.
o Obviously, if two readers access the shared data simultaneously, no adverse effect will result.
o However, if a writer and some other thread (either a reader or a writer) access the database
simultaneously, chaos may ensue.
o To ensure that these difficulties do not arise, we require that the writer have exclusive access
to the shared database.
o The synchronization problem is then referred to as the readers-writers problem.

The Dining Philosophers Problem


o The dining-philosophers problem is considered a classic synchronization problem that aims to
provide a simple representation of the need to allocate several resources among several
processes in a deadlock-free and starvation-free manner.

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