Real-Time Operating Systems Homework Report

Real-Time Operating Systems Homework Report
Vittorio Giovara
26/01/2009
Abstract
In this document a solution will be described for implementing a concurrent programming
scheme in a real-time operating system.
The first part of the document will carry out the design planning, describing the main
procedures and functions in pseudo-code and taking care of two possible issues, deadlock
and starvation. Moreover an actual implementation of the problem will be discussed for the
RTEMS Operating System.
In the second part a complete working implementation of the solution will be presented
for a general purpose operating system, providing profiling and time analysis.
Contents
I Preparation 2
1 The pseudo-code 2
1.1 Functions and Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Dealing with deadlock and starvation issues 3

2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Proof for deadlock free solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Starvation free condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Initial RTEMS solution 4
II Implementation 6
4 Development details 6
4.1 IPC Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Profiling 7
5.1 Testcases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Mean and Maximum Wait Time . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3 Execution Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1
Part I
Preparation
1 The pseudo-code
1.1 Functions and Structures
• void sync (int w)
function for normal processes to put themselves in a passive wait; the argument w represent
the weight of the wait;
• void admit (int a)

function for the master process to wake up some the waiting processes; the argument a
determines which processes in the pool are actived;
• send and recv

functions for implementing message passing with fixed lenght format; the naming scheme
is direct, asymmetric for the asynchronous send with infinite buffer.
• information vector
contains general data about every process: it stores the process identifier, its status (blocked
or running), its weight and the age, which counts how many times a process eligible for
activation has not been woken up after an admit; an additional field is required for the
final solution to work, that is the fdlisten, need for communicating with the process;
• vector order
is a vector containing the ordered (by age) list of all the processes that are activated by an
admit;
1.2 Proposed Solution

void sync (int w)
1. check if the argument w is greater or equal than 1 and less or equal than 10;
2. inform M of the status change with a send;
3. perform a blocking recv;
4. upon message receiving, check if the format is correct;
5. if the message is correct, return, else remain in wait.
void admit (int a)
1. send a message asking the server to perfom the wake up of some processes;
2. return.
2
server process M
1. spawn a given number of P and Q processes and initilize the “information vector”;
2. enter endless loop
3. wait with a recv for an action to perfom;
4. if a sync has been called, update the status of the process in the information vector;
5. if an admit has been called perform the following:
6. initialize a list (vector of index) for storing the set of processes that are going to be activated
(called “vector order”) ;
7. select the set of waiting processes with their weight and age from the information vector;
8. order the vector from highest age to the lowest and initialize pound equal to a ;
9. for every element in the vector, send a wake up if its weight is less than pound and if pound
minus the weight is positive;
10. when a wake up is sent update the pound by subtracting the weight of the process; in this
way both the conditions of the assignment are respected;
11. update the information vector with the new status for the selected processes and the incre-
mented age for the unselected ones;
12. repeat loop.
1.3 Message Format

The format for the exchanged messages is to use 2 integers (8 bytes); the first integer is used for
distinguishing whether a sync or an admit has been called, while the second integer contains
the argument of the admit (sent from the process Q to the server M).
2 Dealing with deadlock and starvation issues

2.1 Definitions
As with most of concurrent programming schemes, it is possible to incur in two important prob-
lems: deadlock and starvation.
The former is situation whereby a set of processes cannot exit a from a given status because
they are waiting for an event that can be generated only by a process inside the blocked set.
This type of problem cannot be resolved (because deadlock detection algorithms are rarely imple-
mented in the system), but only avoided beforehand, implementing secure states.
The latter on the other hand is a condition in which a given process never manages to access a
resource because other processes gain access before it, even if it is ready to execute. This is also
called indefinite wait. Usually this kind of problem appears in priority scheduling systems with no
aging techniques.
3
2.2 Proof for deadlock free solution
In order for deadlocks to appear, the following four conditions are must appear simultaneously
(Coffman’s Conditions):
• Mutual Exclusion: resource usable by one process at a time;
• Hold and Wait: processes holding resources request for other resources;
• No preempion: resources can be released only by explicit action of the holding process;
• Circular Wait: circular loop chain for resource assignation.
In this implementation there is no risk for deadlocks because the server M handles the processes
only one at a time: in fact a single send can activate the server procedure because there is a single
recv in the loop. Thanks to this implicit serialization, the necessary condition of the circular
wait never occurs, thus neglecting the presence of possible deadlocks.
2.3 Starvation free condition

In order to prevent starvation an aging technique has been introduced in handling the processes:
every activation creates different generations of processes. The oldest processes are always con-
sidered and awakened first, before any newer process may prevail over any of them. Since the
number of possibile processes is finite, it always guaranteed that after a mean wait time (unknow,
yet finite) a given process is awakened.
It is possible to consider a case in which n processes are activated one at a time and no pro-
cesses are blocked; if ta is the activation time for a process, then the total time (T ) for activating
all the processes is exactly
T = n ∗ ta
As n and ta are finite values, also the T wait time is finite, thus neglecting the presence of
starvation which requires an indefinite wait.
3 Initial RTEMS solution

In adapting the proposed solution to the RTEMS operating system, it is possible to find several
issues.
The most relevant problem is that the buffers of the send and recv function are not infnite, due
to hardware and software intrinsic limitations. So one of the following solution must be adopted
when performing a send to a full buffer: either assume that one process can send at most one
message and so allocate a buffer as big as the number of processes generated (which is always
finite), or block the send until the buffer is freed of at least one element. This latter approach
heavily depends on the operating system implementation, but it is safe to assume that RTEMS
manages blocked send buffers correctly, with no starvation or race conditions; for this reason this
last solution is preferrable.
As for the IPC mechanisms available on RTEMS, it is possible to choose between the na-
tive RTEMS functions or the POSIX implementation (rtems message queue send() and
rtems message queue receive(), mq send() and mq receive() respectively). The
POSIX mechanism allows to block the send functions when the buffer is full and do not require
modifcation to the proposed solution (carefully handling differences in the naming scheme), so it
should be selected over the native functions.
4
One final minor problem may be byte ordering that should be considered when dealing with
message passing on different architectures; since it has been assumed that the processes run on a
same machine it is possible to neglect this problem.
5
Part II
Implementation
4 Development details
The proposed solution has been implemented on Mac OS X 10.5.6, but as design choice only
ANSI POSIX compliant directives have been used, resulting in highly portable code. As a matter
of fact the program has been tested (and proved working) on Linux with kernel 2.6.24 and on
Solaris (SunOS 5.19) over an UltraSPARC IIi.
The solution heavily relies on wrappers for error checking and error analysis, as well as the
errlib library by W. Richard Stevens for error reporting and general Input/Output management.
Resource allocation is carefully considered (foreseeing a possible real-time port) and in fact when
server and process are closed, socket descriptors are closed, pipes removed, memory deallocated
and child processes killed.
It is possible to select the level of verbosity for info and debug message by passing the TRACE
and DEBUG symbols at compile time, while passing TIMETEST enables timing functions to be
activated.
Before starting the program asks the user to insert the number of processes of type P and
to select the behiavior of the processes: actually the user can either choose to let the processes
generate a random number or interact actively with an interface. In the first case the process sleeps
for that random amount of time (only to prserve readability of the output; the program works even
without the sleep() clauses) and then use that value to perform block or wake up. In the second
case the user is prompted to an interface that allows process selection with PID and value insertion
for the sync() and admit() (as well as a clean closing for the program); the interface process
is generated only when interactive behavior is chosen.
4.1 IPC Mechanisms

In order to let the process exchange packets the underlying Inter Process Comunication chosen is
the Unix socket: every child process generated is connected with the father through a connected
socket with the socketpair() function. Then the server remains in listening mode on all of
them with a select() and as soon as data arrives it selects the correct socket and proceeds
unpacking the message.
When the server needs to send a message to a child process (usually to activate it), it can obtain
the process’ socket (which is included in the information vector) searching in the data structure
using the PID as key.
On the other hand in order to allow interaction, the processes are connected to the interface
with a named pipe. Pipes have been chosen over a second set of sockets because they offer one-
way message passing, instead of socket full-duplex channels; since the interface has only to send
commands to the processes (and not receive any reply back), pipes offer resource-light facility
for the task. The interface spawn a sub process to actually send data so to implement a timeout
condition; in this way the user is informed when a process is already blocked and that it is not
possible to block it again.
Having both sockets and pipes as dedicated channels, integrity of the packets exchanged with
send, recv, write and read is preserved; it is impossible to create conflicts because messages
are sent one at a time.
6
5 Profiling
5.1 Testcases
The following sets of trace of execution from the program are obtained with both random test
cases and with interactive input test. These test aim to cover all the relevant part of code describing
correct functionality of the algorithm, process interaction and concurrent behavior; thanks to the
the fork() approach, no critical regions needed to be defined.
Output may have been reduced with respect to the actual produced to preserve readability.
Tests have been performed on Mac OS X, Linux and Solaris.
Basic functionality In the following test case, the algorithm functionality will be taken in con-
sideration. Five P processes are being generated and each of them performs a sync with a given
value; Q sends an admit capable of activating only four of them and so only four are woken up,
increasing the age of 8500.
Then two of the activated processes perform other sync’s; at the next admit of 8 from Q, the
first process to be awakened is the one that was left behind (8500) as it respects the given conditions
and avoids starvation. Also process 8502 can be activated and it is awakened right away.
Now processes 8501 and 8498 have their age increased and so are candidate to be activated at
next sync; however Q sends a very low admit and so they have to be discarded in favour of 8500
which has just perfomed an equally low sync. They will be activated by the next admit of Q.
(./rtos-hw2) info - 8497 spawned child 8498 (element number 0)

(./rtos-hw2) P:8498 sent a sync(2)
(./rtos-hw2) server received a sync(2) from P:8498
(./rtos-hw2) Q:8503 sent an admit(7)
(./rtos-hw2) server received a request for admit(7)
(./rtos-hw2) server sent WAKE UP to process 8498
(./rtos-hw2) P:8498 has been woken up!
7
Interesting interleaving In this trace there is an interesteing case of interleaving between P

and Q an the server response; in fact between the final admit request sent by Q and the server
acceptance there is the server reply that allowed process 8264 to be blocked. So as soon as the
admit request is accepted, instead of issuing a warning for no blocked processes, 8264 is woken
up right away.

(./rtos-hw2) sent WAKE UP to process 8264
8
(./rtos-hw2) process 8264 is set to BLOCKED with weight 1
Interface testing This test demonstrates the capability of the interface process. It detectes all
possible kind of inputs and correctly manages selected processes . This is possible because the
interface is generated as last child when all the other P processes have been generated and so it has
stored in memory all information of the other processes.
In the following program trace it is verified in order:
• blank input
• wrong input (2 fields required)
• non existing process
• wrong weight value (check also performed by the sync function)
• correct input towards a P process
• correct input towards another P process
• attempt to block a blocked process
• correct input towards a Q process
• program closing
You chose 4 P processes and 1 Q process

You chose to operate with the interface
Enter ’<process pid> <value>’ to command the program (’0 0’ to exit)
>
9
(./rtos-hw2) warning - command not correct
> 12345
(./rtos-hw2) warning - command not correct
> 12345 4
(./rtos-hw2) warning - no process 12345 found
> 8232 20
(./rtos-hw2) warning - command not correct (accepted values [1-10])
> 8232 2
> 8233 5
> 8233 9
(./rtos-hw2) warning - could not send packet to 16689! Is it already blocked?
> 8236 7
> 0 0
Closing interface and program. Goodbye!
(./rtos-hw2) info - received signal number 15. Closing server and processes.
Random generation While the previous example was generated through the interface, this test
show a similar functionality but with random generation of values, as well as with a greater number
of processes involved.
From the point of view of functionality, there is not much differnce from the first test case,
apart from the generation of a wrong sync value. This value is detected right away and discarded.
Process Q can autonomously generate an higher value than allowed just to test this case.

10
(./rtos-hw2) warning - wrong weight value for 8303 (received: 11)
11
No blocked processes This test show that after every process has been activated, it may happen
that Q asks for another admit; the server is capable of handling this situation warning that no
blocked processes are present.

(./rtos-hw2) server P:5441 has been woken up!
(./rtos-hw2) server Q:5444 sent an admit(2)
(./rtos-hw2) warning - there are no BLOCKED processes
Blocked processes, admit value too little In this test a P process (8063) is stopped with an high
weight; then Q asks for low value admit. The server detects the blocked process but can’t correctly
acativate it.
(./rtos-hw2) info - Interface 8065 is born from 8059

> 8063 10
> 8064 2
(./rtos-hw2) interface - writing packet on /tmp/rtos-pipe-8064
(./rtos-hw2) ingo - Q:8064 received a packet containg 2
(./rtos-hw2) admit value too little to wake up any process
5.2 Mean and Maximum Wait Time

As hinted in 2.3 it is possible to compute the maximum wait time given the number of processes
and the period for admitting. For this purpose the wrost case scenario must be considered:if
Pi performs a sync(5), at wrost there will be higher priority (that is with greater age) processe.
Supposing that every admit manages to wake up only one of them at a time, Pi will be awakened
only at the last period of execution.
12
Since by hypothesis an admit is executed every 50 ns and there are 4 process, the maximum
wait time for any process PI is given by:
Tmaxwait = 50ms ∗ 4 = 200ms

As for the mean time it has been computed with the following reasoning.
Since there are only 4 P processes it may happen that Pi is in one of four possible cases:
1. Pi has the highest priority;
2. Pi has the highest priority but there is another process with same priority (Pj );
3. Pi has the highest priority but there are other two processes with same priority (Pj , Pk );
4. Pi has the highest priority but there are other three processes with same priority (Pj , Pk , Pl ).
For every case Pi will have to wait for an amount of time if
1. no wait;
2. wait if the sync value of Pj is > 5;
3. wait if the sum of the sync values of Pj and Pk is > 5;
4. wait if the sum of the sync values of Pj , Pk and Pl is > 5;
It has been computed that the probability for the last three to happen is 50%, 69% and 96%
respectively.
Since it has been supposed that the processes are independent between each other, it is possible
to compute a mean probability of 71,6%.
Finally, to compute the mean time waiting it is sufficient to compute
Tmeanwait = 50ms ∗ 71, 6% = 35, 83ms
5.3 Execution Time

In order to compute the execution time for sync() and admit() the function gettimeofday()
has been used. At function start the time is recorded in a timeval structure and substracted to the
time sampled at function end; then data is converted in µs which is the maximum resolurion of
the clock. Since blocking time doesn’t have to be computed, time in sync() is sampled twice
leaving out the blocking recv().
The test program has been embedded in the final solution and it is accessible by passing the
symbol TIMETEST at compile time; this symbol removes also any I/O function that may nega-
tively influence the computation.
There is a certain amount of uncertainty regarding the computed time. As a matter of fact res-
olution of µs is not guaranteed by ANSI C and the POSIX function gettimeofday() relies on
internal constants (such as CLOCKS PER SEC) that might differ in many implementations. More-
over the hardware ticker present in computers may have a different resolution and uncertainty, so
results can be heavily hardware dependent.
A statistical approach has been used by sampling the amount of time in different situations
(like different number of P processes); usually the first time the function is executed has an higher
value, most likely due to loading in cache operations.
13
Function Execution Time
sync() 28.2 µs
admit() 15.4 µs
14

Real-Time Operating Systems Homework Report

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Real-Time Operating Systems Homework Report

Uploaded by

Copyright:

Available Formats

Real-Time Operating Systems Homework Report

2 Dealing with deadlock and starvation issues 3

3 Initial RTEMS solution 4

• void admit (int a)

• send and recv

1.2 Proposed Solution

2. inform M of the status change with a send;

3. perform a blocking recv;

4. upon message receiving, check if the format is correct;

5. if the message is correct, return, else remain in wait.

void admit (int a)

2. enter endless loop

3. wait with a recv for an action to perfom;

5. if an admit has been called perform the following:

12. repeat loop.

1.3 Message Format

2 Dealing with deadlock and starvation issues

• Mutual Exclusion: resource usable by one process at a time;

• Circular Wait: circular loop chain for resource assignation.

2.3 Starvation free condition

3 Initial RTEMS solution

4.1 IPC Mechanisms

(./rtos-hw2) info - 8497 spawned child 8498 (element number 0)

Interesting interleaving In this trace there is an interesteing case of interleaving between P

(./rtos-hw2) P:8265 sent a sync(1)

• wrong input (2 fields required)

• non existing process

• wrong weight value (check also performed by the sync function)

• correct input towards a P process

• correct input towards another P process

• attempt to block a blocked process

• correct input towards a Q process

You chose 4 P processes and 1 Q process

(./rtos-hw2) info - 8300 spawned child 8303 (element number 0)

(./rtos-hw2) P:5440 sent a sync(1)

(./rtos-hw2) info - Interface 8065 is born from 8059

5.2 Mean and Maximum Wait Time

Tmaxwait = 50ms ∗ 4 = 200ms

1. Pi has the highest priority;

For every case Pi will have to wait for an amount of time if

2. wait if the sync value of Pj is > 5;

3. wait if the sum of the sync values of Pj and Pk is > 5;

4. wait if the sum of the sync values of Pj , Pk and Pl is > 5;

Tmeanwait = 50ms ∗ 71, 6% = 35, 83ms

5.3 Execution Time

You might also like