0% found this document useful (0 votes)
57 views6 pages

Assignment-4 Operating Systems-Ii: System Model Overview

The document describes an operating systems assignment that simulates a Korean restaurant problem using threads. The main thread creates child threads to represent customers entering the restaurant. It uses semaphores to control access to a table with a limited number of seats. The assignment records timing information for customer requests, access grants, and exits in log files. Functions are defined for the restaurant simulation, sorting logs, and merging logs. Graphs analyze how average waiting time varies with the number of customers and seating capacity.

Uploaded by

SNEHIL RAJ
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)
57 views6 pages

Assignment-4 Operating Systems-Ii: System Model Overview

The document describes an operating systems assignment that simulates a Korean restaurant problem using threads. The main thread creates child threads to represent customers entering the restaurant. It uses semaphores to control access to a table with a limited number of seats. The assignment records timing information for customer requests, access grants, and exits in log files. Functions are defined for the restaurant simulation, sorting logs, and merging logs. Graphs analyze how average waiting time varies with the number of customers and seating capacity.

Uploaded by

SNEHIL RAJ
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/ 6

ASSIGNMENT-4

OPERATING SYSTEMS-II
Amitanshu Sahoo
ME18BTECH11050

SYSTEM MODEL OVERVIEW


The system in place is a centralized implementation system where a main thread is calling the
children thread to carry out the function designated to them. The main thread in question here is the
main function itself. The children thread and the customers to the restaurant share one to one
relationship i.e., each children thread is a customer wanting to acquire a seat in the restaurant. All the
time decisions are taken in the main thread and the children just take part in running the semaphore
functions. The arrival delays into the restaurant (which is exponentially distributed) is implemented
within the main thread. The main thread also decides the exponentially distributed eating time based
on the factor gamma and the value is passed a parameter in a structure made for a customer entering
the restaurant function as a thread. The uniformly distributed number of people are also a decision
taken by the main thread.
So, the main thread functions to allow uniformly distributed number of people after every
exponentially distributed time delay with factor “lambda” to enter the restaurant and spend an
exponentially distributed eating time with factor “gamma” in the restaurant.

STRUCTURE USED
There is only one structure that is used in the code to pass the parameters related to a single customer
while creating a thread. The structure is hence named “customer”. It takes two arguments which are.

• The process/customer ID
• The eating time of the customer in the restaurant
The decision for eating time can also be taken while the person is eating inside the “restaurant”
function. However, this implementation is merely cosmetic in nature and does produce any different
result from the implementation used here.

FUNCTION DESCRIPTION
There are three functions that are used in the code: -
I. restaurant function – This is the function which simulates the Korean restaurant
problem and is described in detail in the next section.
II. insertion sort function – The insertion sort function is used to sort the log file arrays as
described below in order of the time stamps at which they occur.
III. merge function – It is used to merge the log file arrays after they are sorted to obtain a
master log file which in turn is printed to the output file.
RESTAURANT FUNCTION
The restaurant function is function which implements the Korean restaurant problem. It uses two
binary semaphores “mutex” and “block”. The mutex lock is initialized such that it is unlocked, and
the block lock is locked at initialization. The variables “eating” and “waiting” store the number of
people eating at the table and the number of people waiting to be admitted to the table, respectively.
The pseudocode describing the algorithm is given as follows: -
Void *restaurant (arguments in the form of structure) {

The values of the passed structure are stored in a structure variable named “person”.

The gettimeofday function is called to store the request time values in timeval struct instance “req”.

The value stored in “req” is stored in the “req_time” log file.

The access request statement is stored in the “log_req_file” array.

Wait(mutex) is called here and the lock is acquired.

If (All the seats are full or (X+1) th person has arrived) {

Waiting variable is incremented.

Must_wait = true.

Mutex lock is released for other process to come in.

All the process now waits at wait(&block) statement for signal to get into critical section.

The gettimeofday function is called to store the access time values in timeval struct instance “acc”.

The value stored in “acc” is stored in the “acc_time” log file.

The access request statement is stored in the “log_acc_file” array.

Else {

Eating variable is incremented.

The must_wait variable (which signifies the formation of group) is set to true according to the condition
if there is someone waiting and the number of at the table is equal to X.

Mutex lock is released for other process to come in.

The gettimeofday function is called to store the access time values in timeval struct instance “acc”.

The value stored in “acc” is stored in the “acc_time” log file.

The access request statement is stored in the “log_acc_file” array.

The process starts eating here as it is the critical section.

Mutex lock is acquired.

The gettimeofday function is called to store the exit time values in timeval struct instance “ext”.

The value stored in “acc” is stored in the “ext_time” log file.

The access request statement is stored in the “log_ext_file” array.

Eating variable is decremented.


If (no one is eating at the table) {

Variable k is defined by the minimum of X and waiting variable.

Waiting variable is decremented by k.

Eating variable is incremented by k.

The must_wait variable (which signifies the formation of group) is set to true according to the condition
if there is someone waiting and the number of at the table is equal to X.

The block semaphore is signalled k times to allow the waiting processes to acquire the table.

Mutex lock is released.

When the table has vacant seats, the incoming processes execute the first else statement and proceed
to the critical section. When all the seats are taken, and a group is formed the incoming processes are
blocked by the block semaphore.

If people start leaving from the table when the group is already formed, the waiting processes are not
allowed into the critical section until the last process leaves the table and signal the waiting processes.
In case the number of waiting processes is greater than X it only signal X processes to come to the
critical section and again form a group. If the number of waiting processes is less than X, then it
simply allows them into the critical section and no group is formed.

FILE IMPLEMENTATION DESCRIPTION


Strings used in the file implementation are: -
I. log_file_req [] – It stores the request statements by the processes when the processes request
for the critical section.
II. log_file_acc [] – It stores the access statements by the processes when the processes access
the critical section.
III. log_file_ext [] – It stores the exit statements by the process when the process leaves the
critical section.
IV. master_log_file [] – It stores the time stamp sorted log statements of the processes to be
printed to the file.
Double arrays used in the file implantation are: -
I. req_time [] – It stores the request statement time stamps.
II. acc_time [] – It stores the access statement time stamps.
III. ext_time [] – It stores the exit statement time stamps.
IV. master_time_log [] – It stores all the sorted time stamps.
CODE FLOW
• In the starting all the required variables and structures are defined. After that, the three
function “restaurant”, “insertion_sort” and “merge” function are defined.
• In the main function firstly the start time of the function is recorded by the timeval struct
instance “start”.
• Then the two binary semaphores to be used by the threads are defined.
• The required inputs are taken from the “input.txt” file.
• After this the exponential distribution instances with factor lambda and gama are defined
named as “arrival_time” and “eating_time” and uniformly distributed instance is defined
named as “numpeople”.
• Then the variables num_threads and count are defined. Count variable is initialized to zero. N
instances of threads and structure for each thread are called.
• In the while loop until count becomes equal to N i.e., until the number of customers in the
restaurant are less than N, the following flow continues: -

1. Loop is put into sleep to simulate time delay.


2. Set of customers are chosen for thread creation.
3. Threads are created and structure is initialized for each thread with the ID and
eating_time and passed as argument.
4. Count variable is checked if it is equal to N or not. If it is equal to N, the loop breaks.
• All the threads are joined.
• All the log files are sorted according to the time stamp and a master log file is contructed
and merged. The master log file is then printed to the “output.txt” file.
• The average waiting time is calculated using the request and access log file. The computed
average waiting time is then printed to the screen.
GRAPHS AND ANALYSIS
GRAPH TABLE

• The values for the graphs have been averaged over 5 readings at each abscissa point.
• lambda = 1.5, gamma = 0.75, r = 2.

AVERAGE WAITING TIME VS NUMBER OF THREADS

• As the number of threads are increasing the average waiting time is also increasing
(keeping the number of participants on the table constant at 4). This is because as the
number of threads are increasing there is more chance of a situation where more
threads are waiting.
AVERAGE WAITING TIME VS X

• Average waiting time is decreasing if the number of participants on the table are
increasing keeping the total number of customers constant. This is to be expected
because if we increase X, we are essentially letting more people into the critical
section at the same time. Hence the amount of time a single process waits for
decreases.

NOTE :- All the times displayed in the output log file are with respect to the start time as
stored by the timeval struct instance “start” at the starting of the execution of main().

You might also like