BLG305

Operating systems
 LESSON - 1

Asst. Assoc. Dr. Önder EYECİOĞLU

Computer engineering
 WEEK TOPICS

Entrance Week : Introduction to operating systems, Operating

1 system strategies

Lesson Day and Time: Week : System calls

Monday: 09:15-11:25 2
• Application Unix (Linux) Operating system
• Attendance requirement 70% Week : Task, task management
• Applications will be implemented on the C programming 3
language. Programming knowledge is expected from
Week : Threads
students.
• • Grading: Midterm ‐>30%, Final ‐>60%, Homework ‐ 4
>10%
Week : Job ranking algorithms
5

Week : Inter-task communication and synchronization

6

Week : Semaphores, Monitors and applications

7

Week : Visa
8

Week : Critical Region Problems

9
CLASSICAL SYNCHRONIZATION PROBLEMS
Semaphore can also be used in other synchronization problems besides Mutual Exclusion.
Below are some of the classic problems that illustrate the flaws of process synchronization in
systems where collaborating processes exist.
We will discuss the following three issues:

Limited Buffer (Producer-Consumer) Problem

The Problem of Feeding Philosophers
• The Literacy Problem
Limited Buffer (Producer-Consumer) Problem
The limited buffer problem, also called the producer-consumer problem, is one of the classic
problems of synchronization.
There is a buffer of n slots, and each slot is capable of storing one unit of data. There are two
processes that work on the buffer, that is, the producer and the consumer.
Limited Buffer (Producer-Consumer) Problem
A manufacturer tries to insert data into an empty slot of the buffer. A consumer tries to remove
data from a populated slot in the buffer. As you can guess by now, if these two processes are
executed at the same time, it will not produce the expected output.
There must be a way to ensure that the producer and the consumer work independently.
Limited Buffer (Producer-Consumer) Problem

One solution to this problem is to use a semaphore. The semaphores to be used here are:
m is a binary semaphore used to pick up and release the lock.
Empty is a counting semaphore whose initial value is the number of slots in the buffer
because all slots are empty at startup.
full, a counting semaphore with an initial value of 0.
At any given moment, the null value represents the number of empty slots in the buffer, and
full represents the number of filled slots in the buffer.
Limited Buffer (Producer-Consumer) Problem

PRODUCER
Limited Buffer (Producer-Consumer) Problem

PRODUCER
Looking at the above code for a manufacturer, we can see that a manufacturer waits
until there is at least one empty slot first.
It then reduces the free semaphore, because the manufacturer will add data to one of
these slots, so there will now be one less empty slot.
It then locks on the buffer so that the consumer cannot access it until the producer
completes its operation.
After performing the insert operation, the lock is released and the full value is
increased because the manufacturer has filled a slot in the buffer.
Limited Buffer (Producer-Consumer) Problem
CONSUMER
LIMITED BUFFER PROBLEM

CONSUMER
The consumer waits until there is at least one full slot in the buffer.
It then reduces the full semaphore because the number of occupied slots will decrease one by
one after the consumer completes the transaction.
After that, the consumer obtains a lock on the buffer.
Following this, the consumer completes the removal process to remove the data from one of
the occupied slots.
Then, the consumer releases the lock.
Finally, the empty semaphore 1 is incremented because the consumer has just extracted data
from a full slot, thus leaving it empty.
DİNİNG PHİLOSOPHERS
In 1965, Dijkstra posed and then solved a
synchronization problem that he called the Dining
philosophers.
The problem of feeding philosophers involves the
allocation of limited resources without being
locked into a group of processes and free from
hunger.
DİNİNG PHİLOSOPHERS

The problem can be expressed quite simply as

follows. Five philosophers sit around a round table.
Every philosopher has a plate of spaghetti.
Spaghetti is so slippery that a philosopher needs
two forks to eat it. A fork is located between each
pair of plates.
DİNİNG PHİLOSOPHERS

The life of a philosopher consists of successive

periods of eating and thinking. (This is a kind of
abstraction, even for philosophers, but other
activities are irrelevant here.) When a philosopher
is hungry enough, he tries to get his left and right
forks one at a time, in both rows. If he manages to
get two forks, he eats for a while, then puts down
the forks and continues to think. The key question
is: Can you write a program for every philosopher
that does what it's supposed to do and never gets
stuck?
DİNİNG PHİLOSOPHERS

The take fork waits until the specified fork

becomes available and then retrieves it.
Unfortunately, the obvious solution is wrong.
Suppose all five philosophers take their left forks at
the same time. None of them will get their right fork
and will hit a dead end.
Dining philosophers
DİNİNG PHİLOSOPHERS

We can easily modify the program so that after

receiving the left fork, the program checks if the
correct fork is available. If not, the philosopher
leaves the left, waits for a while, and then repeats
the whole process. This proposal also fails, albeit
for a different reason. With a bit of bad luck, all
philosophers can start the algorithm at the same
time, take their left fork, see that their right fork is
not available, let go of their left fork, wait, pick up
their left fork again at the same time, and so on
forever.
DİNİNG PHİLOSOPHERS

Such a situation, in which all programs continue

indefinitely but do not make any progress, is called
starvation.
Another problem encountered in the problem is
deadlock. As a result of a wrong design, a
philosopher who takes a single fork and waits for
the other philosopher to quit can lock the system.
This is the second risk found in the problem.
DİNİNG PHİLOSOPHERS

Semaphore Solution
A simple solution is to represent each bar with a
semaphore. A philosopher tries to capture a rod by
executing a wait() operation on that semaphore. It
releases chopsticks by executing the signal()
operation at the appropriate semaphores.
DİNİNG PHİLOSOPHERS

Semaphore Solution
Structure of a random philosopher i
DİNİNG PHİLOSOPHERS

Semaphore Solution
Although this solution guarantees that two
neighbors do not eat at the same time, it should
still be rejected, since it can create a deadlock.
Suppose all five philosophers were hungry at the
same time, and each of them was holding the left
chopstick. All elements of the bar will now be equal
to 0. Every time a philosopher tries to get the right
stick stick, it will be postponed forever.
 DİNİNG PHİLOSOPHERS

Semaphore Solution
A few possible solutions to the crash issue are as
follows:
• Allow no more than four philosophers to sit at the
table at the same time.
• Allow a philosopher to take chopsticks only if both
sticks are present (to do this, he must pick them up
from a critical section).
• Use an asymmetrical solution—that is, an odd-
numbered philosopher takes the left bar first and then
the right bar bar, while an even-numbered philosopher
takes the right bar bar and then the left bar bar
READER-WRITER PROBLEM
The problem of food philosophers is useful for modeling
processes competing for exclusive access to a limited
number of resources, such as I/O devices. Another
famous problem is the problem of readers and writers
modeling access to a database (Courtois et al., 1971).
Consider, for example, an airline reservation system with
many competing processes that require reading and
writing. It is acceptable to have multiple processes
reading the database at the same time, but if one
transaction is updating (writing) the database, no other
process may have access to the database, not even
readers. The question is, how do you program readers
and writers?
READER-WRITER PROBLEM

In this problem, there are some processes (called

readers) that only read the shared data and never modify
it, and there are other processes (called writers) that can
modify the data in addition to or instead of reading it.
There are various types of literacy issues, most of which
focus on the relative priorities of readers and writers.
The main complexity in this problem comes from allowing
multiple readers to access data at the same time.
READER-WRITER PROBLEM

The readers/authors problem is defined as:

There is a data field that is shared between a set of
processes. The data space can be a file, a block of main
memory, or even a bank of processor records. There are
a number of operations that only read the data field
(readers) and write only to the data field (writers). The
conditions that must be met are as follows:
Any number of readers can read the file at the same time.
Only one author can write to the file at a time.
If an author is writing in the file, no reader can read it.
READER-WRITER PROBLEM

There are several variations of the literacy problem, all of

which involve priorities. The simplest problem, called the
first reader-to-author problem, requires that no reader be
kept waiting unless an author has already received
permission to use the shared object. In other words, no
reader should expect other readers to finish just because
one author is waiting. The second reader-writer problem
requires that when a writer is ready, that writer must
perform his writing as soon as possible. In other words, if
an author expects to access the object, no new reader
will be able to start reading.
READER-WRITER PROBLEM

Solution
In solving the initial reader-to-writer problem, reader
processes share the following data structures:

and binary semaphores are initialized as 1; is a counting

semaphore that starts as 0. semaphore is common to
both the reader and author processes.
 READER-WRITER PROBLEM

When the variable number of reads is updated, the

mutex semaphore is used to ensure mutual exclusion.
read_count variable keeps track of how many
processes are currently reading the object.
rw_mutex semaphore functions as a common
exclusion semaphore for authors. It is also used by the
first or last reader to enter or exit the critical section. It is
not used by readers who enter or exit when other readers
are in their critical sections.
READER-WRITER PROBLEM
READER-WRITER PROBLEM
READER-WRITER PROBLEM

Note that if an author is in the critical section and n

readers are waiting, then one reader is queued in
rw_mutek, and n−1 readers are queued on the mutex.

Also, observe that when an author executes signal(rw

mutex), we can proceed with the execution of waiting
readers or a single waiting author. The selection is made
by the timer.
READER-WRITER PROBLEM

The literacy problem and its solutions have been

generalized to provide reader-to-liter locks in some
systems. Obtaining a reader-writer lock requires
specifying the lock's mode: either read or write access.
When a process only wants to read shared data, it
requests the reader-writer lock in read mode. A process
that wants to modify shared data must request the lock in
write mode. Multiple processes are allowed to take a
reader-writer lock at the same time in read mode, but only
one process can take the lock for writing because special
access is required for authors.
READER-WRITER PROBLEM

Reader-writer locks are most useful in the following

situations:
• In applications where it is easy to determine which
processes only read shared data and which processes
only write shared data.
• In applications that have more readers than authors.
This is because reader-to-author locks typically require
more overhead to create than semaphores or mutually
exclusive locks. The increased concurrency of allowing
multiple readers compensates for the overhead
associated with setting the reader-author lock.