1

1.1

The Dining Philosophers Problem

Aim

Solve Dining Philosophers Problem using semaphores

1.2

Dining Philosophers Problem

The Dining Philosophers problems is a classic synchronization problem (E.

W. Dijkstra. Co-operating Sequential Processes. In F. Genuys (ed.) Programming Languages, Academic Press, London, 1965) introducing semaphores
as a conceptual synchronization mechanism. There is a dining room containing a circular table with five chairs. At each chair is a plate, and between each
plate is a single chopstick. In the middle of the table is a bowl of spaghetti.
Near the room are five philosophers who spend most of their time thinking,
but who occasionally get hungry and need to eat so they can think some
more.
In order to eat, a philosopher must sit at the table, pick up the two
chopsticks to the left and right of a plate, then serve and eat the spaghetti
on the plate.
Thus, each philosopher is represented by the following pseudocode:
process P[ i ]
w h i l e t r u e do
{ THINK;
PICKUP(CHOPSTICK[ i ] , CHOPSTICK[ i +1 mod 5 ] ) ;
EAT;
PUTDOWN(CHOPSTICK[ i ] , CHOPSTICK[ i +1 mod 5 ] )
}
A philosopher may THINK indefinately. Every philosopher who EATs will
eventually finish. Philosophers may PICKUP and PUTDOWN their chopsticks in either order, or nondeterministically, but these are atomic actions,
and, of course, two philosophers cannot use a single CHOPSTICK at the
same time.
The problem is to design a protocol to satisfy the liveness condition: any
philosopher who tries to EAT, eventually does.

1.3

Tannenbaums Solution

This solution uses only boolean semaphors. There is one global semaphore
to provide mutual exclusion for exectution of critical protocols. There is one
semaphore for each chopstick. In addition, a local two-phase prioritization
scheme is used, under which philosophers defer to their neighbors who have
declared themselves hungry. All arithmetic is modulo 5.
system DINING PHILOSOPHERS
VAR
me :
semaphore , i n i t i a l l y 1 ;
s [ 5 ] : semaphore s [ 5 ] , i n i t i a l l y 0 ;
p f l a g [ 5 ] : {THINK, HUNGRY, EAT} , i n i t i a l l y THINK;

/ f o r mutual e x c l u s i o
/ f o r s y n c h r o n i z a t i o n
/ p h i l o s o p h e r f l a g /

As b e f o r e , each p h i l o s o p h e r i s an e n d l e s s c y c l e o f t h i n k i n g and e a t i n g .
procedure philosopher ( i )
{
w h i l e TRUE do
{
THINKING ;
take chopsticks ( i );
EATING;
drop chopsticks ( i ) ;
}
}
The take chopsticks procedure involves checking the status of neighboring
philosophers and then declaring ones own intention to eat. This is a twophase protocol; first declaring the status HUNGRY, then going on to EAT.
procedure take chopsticks ( i )
{
DOWN(me ) ;
/ c r i t i c a l s e c t i o n /
p f l a g [ i ] := HUNGRY;
test [ i ] ;
UP(me ) ;
/ end c r i t i c a l s e c t i o n /
2

/ Eat i f e n a b l e d /

DOWN( s [ i ] )
}

void t e s t ( i )
/ Let p h i l [ i ] eat , i f w a i t i n g /
{
i f ( p f l a g [ i ] == HUNGRY
&& p f l a g [ i 1] != EAT
&& p f l a g [ i +1] != EAT)
then
{
p f l a g [ i ] := EAT;
UP( s [ i ] )
}
}
Once a philosopher finishes eating, all that remains is to relinquish the
resourcesits two chopsticksand thereby release waiting neighbors.
void drop chopsticks ( i n t i )
{
DOWN(me ) ;
t e s t ( i 1);
t e s t ( i +1);
UP(me ) ;
}

/
/
/
/

c r i t i c a l s e c t i o n /
Let p h i l . on l e f t e a t i f p o s s i b l e /
Let p h i l . on r g h t e a t i f p o s s i b l e /
up c r i t i c a l s e c t i o n /

The protocol is fairly elaborate, and Tannenbaums presentation is made

more subtle by its coding style.

OS Lab

Bankers Algorithm
Aim
Implementation of Bankers Algorithm

Theory
The Banker's algorithm, sometimes referred to as the avoidance algorithm, is a resource
allocation and deadlock avoidance algorithm that tests for safety by simulating the allocation of
predetermined maximum possible amounts of all resources, and then makes an "s-state" check
to test for possible deadlock conditions for all other pending activities, before deciding
whether allocation should be allowed to continue.
When a new process enters a system, it must declare the maximum number of instances of
each resource type that it may ever claim; clearly, that number may not exceed the total
number of resources in the system. Also, when a process gets all its requested resources it
must return them in a finite amount of time.
Let n be the number of processes in the system and m be the number of resource types. Then
we need the following data structures:

Available: A vector of length m indicates the number of available resources of each

type. If Available[j] = k, there are k instances of resource type Rj.

Max: An nm matrix defines the maximum demand of each process. If Max[i,j] = k,

then Pi may request at most k instances of resource type Rj .

Allocation: An nm matrix defines the number of resources of each type currently

allocated to each process. If Allocation[i,j] = k, then process Pi is currently allocated k

instances of resource type Rj .

Need: An nm matrix indicates the remaining resource need of each process. If

Need[i,j] = k, then Pi may need k more instances of resource type Rj to complete the
task.

Note: Need[i,j] = Max[i,j] - Allocation[i,j].

Allocationi specifies the resources currently allocated to process Pi and Needi specifies the additional
resources that process Pi may still request to complete its task.
Bankers algorithm consist of Safety algorithm and Resource request algorithm

Safety Algorithm
The algorithm for checking whether a system is in safe state or not is as follows
1.

Initialize work = available

Finish[i] = false for 1..n
2. Find an i such that both
a. Finish[i] = false
b. need[i]<=work
If no such i exists go to 4
3. Work = work + allocation[i]
Finish[i] =true
Goto 2
4. If finish[i]= true for all i then system is in safe state

Resource Request algorithm

Let Requesti be the request array for process Pi. Requesti [j] = k means process Pi wants k instances of
resource type Rj. When a request for resources is made by process Pi, the following actions are taken:
1.

If request[i] <=need[i]
Goto 2, otherwise raise error

2.

If request[i] <=available
Goto 3 otherwise process must wait

3.

Available = available - request

Allocation[i] = allocation[i] + request
Need[i] = need[i] - request[i]

1
1.1

File System Statistics

Name

statvfs, fstatvfs - get file system statistics

1.2

Synopsis

#include hsys/statvf s.hi

int statvfs(const char *path, struct statvfs *buf);
int fstatvfs(int fd, struct statvfs *buf);

1.3

Description

The function statvfs() returns information about a mounted file system. path
is the pathname of any file within the mounted file system. buf is a pointer
to a statvfs structure defined approximately as follows:
struct statvfs {
unsigned long
unsigned long
fsblkcnt t
fsblkcnt t
fsblkcnt t
fsfilcnt t
fsfilcnt t
fsfilcnt t
unsigned long
unsigned long
unsigned long
};

f bsize ;
f frsize ;
f blocks ;
f bfree ;
f bavail ;
f files ;
f ffree ;
f favail ;
f fsid ;
f flag ;
f namemax ;

/
/
/
/
/
/
/
/
/
/
/

f i l e system b l o c k s i z e /
fragment s i z e /
s i z e o f f s i n f f r s i z e u n i t s /
# f r e e b l o c k s /
# free blocks for unprivileged user
# i n o d e s /
# f r e e i n o d e s /
# f r e e inodes for unprivileged user
f i l e system ID /
mount f l a g s /
maximum f i l e n a m e l e n g t h /

Here the types fsblkcnt t and fsfilcnt t are defined in sys/types.h Both
used to be unsigned long. The field f flag is a bit mask . Bits defined by
POSIX are
ST RDONLY : Read-only file system.
ST NOSUID : Set-user-ID/set-group-ID bits are ignored by exec(3).
It is unspecified whether all members of the returned struct have
meaningful values on all file systems.
1

fstatvfs() returns the same information about an open file referenced by

descriptor fd.

1.4

Return Value

On success, zero is returned. On error, -1 is returned, and errno is set

appropriately.

1.5
1.5.1

Errors
EACCES

(statvfs()) Search permission is denied for a component of the path prefix

of path.
1.5.2

EBADF

(fstatvfs()) fd is not a valid open file descriptor.

1.5.3

EFAULT

Buf or path points to an invalid address.

1.5.4

EINTR

This call was interrupted by a signal.

1.5.5

EIO

An I/O error occurred while reading from the file system.

1.5.6

ELOOP

(statvfs()) Too many symbolic links were encountered in translating path.

1.5.7

ENAMETOOLONG

(statvfs()) path is too long.

1.5.8

ENOENT

(statvfs()) The file referred to by path does not exist.

1.5.9

ENOMEM

Insufficient kernel memory was available.

1.5.10

ENOSYS

The file system does not support this call.

1.5.11

ENOTDIR

(statvfs()) A component of the path prefix of path is not a directory.

1.5.12

EOVERFLOW

Some values were too large to be represented in the returned struct.

SMTP using UDP

1.1 SMTP (Simple Mail Transfer Protocol)
SMTP (Simple Mail Transfer Protocol) is a TCP/IP protocol used in sending and receiving e-mail.
However, since it is limited in its ability to queue messages at the receiving end, it is usually used with
one of two other protocols, POP3 or IMAP, that let the user save messages in a server mailbox and
download them periodically from the server. In other words, users typically use a program that uses
SMTP for sending e-mail and either POP3 or IMAP for receiving e-mail. On Unix-based systems,
sendmail is the most widely-used SMTP server for e-mail.
1.2 UDP (User Datagram Protocol)
UDP (User Datagram Protocol) is an alternative communications protocol to Transmission Control
Protocol (TCP) used primarily for establishing low-latency and loss tolerating connections between
applications on the Internet.
1.2.1 Steps involved in UDP programming:
1. Create a socket:
if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
perror("cannot create socket");
return 0;
}
2. Name a socket:
#include <sys/socket.h>
...
struct sockaddr_in myaddr;
/*
/*
/*
/*
/*
/*
*/
/*
*/

bind to an arbitrary return address */

because this is the client side, we don't care about the address */
since no application will initiate communication here - it will */
just send responses */
INADDR_ANY is the IP address and 0 is the socket */
htonl converts a long integer (e.g. address) to a network representation
htons converts a short integer (e.g. port) to a network representation

memset((char *)&myaddr, 0, sizeof(myaddr));

myaddr.sin_family = AF_INET;
myaddr.sin_addr.s_addr = htonl(INADDR_ANY);
myaddr.sin_port = htons(0);
if (bind(fd, (struct sockaddr *)&myaddr, sizeof(myaddr)) < 0) {
perror("bind failed");

return 0;

3. Send message from server to client:

#include <sys/types.h>
#include <sys/socket.h>
sendto(int socket, const void *buffer, size_t length, int flags, const struct
sockaddr *dest_addr,
socklen_t dest_len)
The first parameter, socket, is the socket that was created with the socket system call and named
via bind. The second parameter, buffer, provides the starting address of the message we want to
send. length is the number of bytes that we want to send. The flags parameter is 0 and not useful for
UDP sockets. The dest_addr defines the destination address and port number for the message. It uses
the same sockaddr_in structure that we used in bind to identify our local address. As with bind, the
final parameter is simply the length of the address structure: sizeof(struct sockaddr_in).
4. Receive messages:
#include <sys/socket.h>
recvfrom(int socket, void *restrict buffer, size_t length, int flags, struct
sockaddr *restrict src_addr,
socklen_t *restrict *src_len)
The first parameter, socket is a socket that we created ahead of time (and used bind. The port number
assigned to that socket via the bind call tells us on what port recvfrom will wait for data. The incoming
data will be placed into the memory at buffer and no more than length bytes will be transferred (that's
the size of your buffer). We will ignore flags here. You can look at the man page forrecvfrom for
details on this. This parameter allows us to process out-of-band data, peek at an incoming message
without removing it from the queue, or block until the request is fully satisfied. We can safely ignore
these and use 0. The src_addr parameter is a pointer to a sockaddr structure that you allocate and will
be filled in by recvfrom to identify the sender of the message. The length of this structure will be stored
in src_len. If you do not care to identify the sender, you can set both of these to zero but you will then
have no way to reply to the sender.
5. Close socket:
With TCP sockets, we saw that we can use the shutdown system call to close a socket or to terminate
communication in a single direction. Since there is no concept of a connection in UDP, there is no need
to call shutdown. However, the socket still uses up a file descriptor in the kernel, so we can free that up
with the close system call just as we do with files.
close(fd);

FTP Using TCP

The File Transfer Protocol (FTP) is a standard network protocol used to transfer computer files
between a client and server on a computer network.
FTP is built on a client-server model architecture and uses separate control and data connections
between the client and the server.[1] FTP users may authenticate themselves with a clear-text sign-in
protocol, normally in the form of a username and password, but can connect anonymously if the server
is configured to allow it. For secure transmission that protects the username and password, and
encrypts the content, FTP is often secured with SSL/TLS (FTPS). SSH File Transfer Protocol (SFTP)
is sometimes also used instead, but is technologically different.

File transfer TCP Algorithm

Server side Filer Transfer TCP Algorithm
STEP 1: Start the program.
STEP 2: Declare the variables and structure for the socket.
STEP 3: Create a socket using socket functions
STEP 4: The socket is binded at the specified port.
STEP 5: Using the object the port and address are declared.
STEP 6: After the binding is executed the file is specified.
STEP 7: Then the file is specified.
STEP 8: Execute the client programming

Client File Transfer TCP programming Algorithm

STEP
STEP
STEP
STEP
STEP
STEP
STEP

1:
2:
3:
4:
5:
6:
7:

Start the program.

Declare the variables and structure.
Socket is created and connects function is executed.
If the connection is successful then server sends the message.
The file name that is to be transferred is specified in the client side.
The contents of the file is verified from the server side.
Stop the program

Simulation of Sliding Window Protocol

Aim:
1. Simulate Stop and wait sliding window protocol
2. Simulate Go Back N sliding window protocol
3. Simulate Selective Repeat sliding window protocol

Theory:
A sliding window protocol is a feature of packet-based data transmission protocols. Sliding
window protocols are used where reliable in-order delivery of packets is required, Eg: in TCP.
Each portion of the transmission is assigned a unique consecutive sequence number, and the
receiver uses the numbers to place received packets in the correct order, discard duplicate
packets and identify missing ones. The problem with this is that there is no limit on the size of
the sequence number that can be required.
By placing limits on the number of packets that can be transmitted or received at any given time,
a sliding window protocol allows an unlimited number of packets to be communicated using
fixed-size sequence numbers. The term "window" on the transmitter side represents the logical
boundary of the total number of packets yet to be acknowledged by the receiver. The receiver
informs the transmitter in each acknowledgment packet the current maximum receiver buffer
size (window boundary).

Stop And Wait

In stop and wait ARQ, the sliding window size is limited to one, i.e a packet is transmitted only
after the acknowledgement for the previous packet is received, else the sender will retransmit
the packet till an acknowledgment is received.
The following transitions occur:

The sender maintains a timeout counter.

When a frame is sent, the sender starts the timeout counter.

If acknowledgement of frame comes in time, the sender transmits the next

frame in queue.

If acknowledgement does not come in time, the sender assumes that either the
frame or its acknowledgement is lost in transit. Sender retransmits the frame
and starts the timeout counter.

If a negative acknowledgement is received, the sender retransmits the frame.

Stop and Wait ARQ

Go Back N ARQ
Stop and wait ARQ mechanism does not utilize the resources at their best.When the
acknowledgement is received, the sender sits idle and does nothing. In Go-Back-N
ARQ method, both sender and receiver maintain a window.

Go Back N ARQ
The sending-window size enables the sender to send multiple frames without
receiving the acknowledgement of the previous ones. The receiving-window
enables the receiver to receive multiple frames and acknowledge them. The
receiver keeps track of incoming frames sequence number.
When the sender sends all the frames in window, it checks up to what sequence
number it has received positive acknowledgement. If all frames are positively
acknowledged, the sender sends next set of frames. If sender finds that it has

received NACK or has not receive any ACK for a particular frame, it retransmits all
the frames after which it does not receive any positive ACK.

Selective Repeat ARQ

In Go-back-N ARQ, it is assumed that the receiver does not have any buffer space
for its window size and has to process each frame as it comes. This enforces the
sender to retransmit all the frames which are not acknowledged.

Selective Repeat ARQ

In Selective-Repeat ARQ, the receiver while keeping track of sequence numbers,

buffers the frames in memory and sends NACK for only frame which is missing or
damaged.
The sender in this case, sends only packet for which NACK is received.