Parallel and distributed algorithms and implementations: time based mutual exclusion

Abstract

A parallel algorithm is required to satisfy mutual exclusion in order to execute all processes properly. To execute Mutual exclusion, there must be required to satisfy these two conditions: synchronization and concurrent execution of all processes. Though failure of process inside the critical region may occur and that makes all other processes to wait until that process exit or stop using that critical region. This may lead to infinite time of wait for other process. This problem might be solved by time based mutual exclusion. In this paper we will present one solution for such failure. We create a new data structure of every critical region which is shared by other processes in the parallel and distributed environment. We introduce timestamp based data structure which tries to recover from such process failure. This timestamp based data structure has certain attributes based on that attributed we will recover from the failure of that process.

Full text

Parallel and Distributed Algorithms and Implementations: Time Based
Mutual
Exclusion
Syed S
. Rizvi, Hemen Patel, Khaled Elleithy
Department of Computer Science, University of Bridgeport, Bridgeport, CT 06604, USA
{srizvi, hemenp, elleithy}@bridgeport.edu
T
e
l
:
9
2 (111) 002-004, Fax:92 (021) 509-0968
Keywords: Distributed algorithms, time based mutual
exclusion, parallel systems.
Abstract
A parallel algorithm is required to satisfy mutual exclusion in
order to execute all processes properly. To execute Mutual
exclusion, there must be required to satisfy these two
conditions: synchronization and concurrent execution of all
processes. Though failure of process inside the critical region
may occur and that makes all other processes to wait until that
process exit or stop using that critical region. This may lead to
infinite time of wait for other process. This problem might be
solved by time based mutual exclusion. In this paper we will
present one solution for such failure. We create a new data
structure of every critical region which is shared by other
processes in the parallel and distributed environment. We
introduce timestamp based data structure which tries to recover
from such process failure. This timestamp based data structure
has certain attributes based on that attributed we will recover
from the failure of that process.
1. INTRODUCTION
Mutual Exclusion is the state in which only one process can
access critical region of the parallel and distributed
environment at a single instance of time [1]. Mutual exclusion
ensure that critical region is being access or enter by a single
process and makes other processes wait or busy who want to
access or enter that same critical region while one process is
already in that critical region. Thus, mutual exclusion requires
some communication between processes to avoid race
condition. Race condition is said to be occurred when more
than one process access and manipulate same critical region at
a same instance of time. This type of communication between
processes is referred as Interprocess communication [2].
Interprocess communication (IPC) is necessary to achieve
synchronization between every process in the parallel and
distributed environment. All processes must have to
communicate with other process to be synchronized to avoid
race condition, deadlock or starvation. To avoid these
parameters, IPC has different approaches or different ways to
communicate with processes [3]. Those approaches or
mechanism are: Pipes, First In First Out (FIFO), Shared
Memory, Mapped Memory, and Message Queues [3, 4].
In the mutual exclusion, whenever a process enters critical
region, it simply has to test or check the lock of that critical
region and if it is set free then and then that process can enter
or access that critical region of the memory in the parallel and
distributed environment. Lock is a data structure in which
process fills its own parameter to set lock. A process can enter
only if lock is set by itself. If any other process has set lock for
a critical region for which current process wants to enter or
access, in such scenario that requesting process has to wait
until the lock is set free by presently accessing critical region.
After accessing critical region or on completing critical region
execution, process set lock to free for that critical region so
that any other process which has been in queue to enter or to
access that critical region. [5]
As process exit from the critical region, it notifies all other
processes by sending message that critical region are free to
access. So, all waiting processes enter that critical region
according to smallest timestamp of the request. There is one
data structure or queue which maintains request of other
processes with the time stamp of the request when one process
is using that critical region. Thus, after setting that critical
region free, process sends message to all other waiting
procedures that resource or critical region is free to enter. Fig.
1 shows illustration of entering a critical region whereas Fig 2
shows illustration of exiting a critical region.
There may be a case of process failure in the critical region.
In such case, presently residing process may dead in the
critical region and hence setting lock free is still left. In this
scenario, all other processes have to wait until the current
process completes it task and sets lock free. This may lead to
infinite time of wait if that process will not recovered or that
critical region’s lock is not set free. There may be a case of
deadlock in such situation.
To overcome this problem, we introduce a data structure in
which we assign duration of the task to that data structure.
After exceeding that duration, one process sets that lock to free
if presently residing process failed to response to that message
of other process. The duration is set according to the parallel
and distributed environment. This is the assumption we made
for the proposed solution of such scenario.
2. REKATED WORK
Mutual Exclusion is necessary to avoid race condition. In
addition, deadlock and starvation are two major issues which
must be taken care while implementing such algorithm [6].
Mutual Exclusion Algorithms should have these three
properties: Deadlock freedom, Mutual Exclusion, and
Starvation Freedom. Mutual Exclusion makes sure that only
one process can access a critical region. Deadlock Freedom
Copyright held by SCS.

guarantees that process will not be blocked forever. Starvation
F
r
e
edom guarantees that requesting process will not be waited
forever to access that critical region [7]. These three properties
are must for an efficient execution of an algorithm. Examples
of such algorithms are [8]. For instance, [8] described an
algorithm for the distributed system for the group mutual
exclusion which takes care of mutual exclusion for the group
of processes in the distributed environments. All these
algorithms can satisfy mutual exclusion properties. However,
they provide no provision for the failure of process in the
critical section.
3. PROPOSED TIME STAMP BASED ALGORITHM
In our proposed algorithm, we maintain a queue for the
incoming request for the critical sections with the duration of
use of time for that critical section. Here, we assumed that
critical section is shared memory, which is shared by all the
processes in the parallel computing. Now each shared memory
has a queue for the incoming requests and based on that queue
data structure, we can able to modify our algorithm as per
need. We can get variation like First Come First Serve for
incoming request or we can modify based on priority or based
on duration of use of time. So, such kind of variation might be
there as per it is needed. As of now, we will assume that our
algorithm follows First Come First Serve bases.
Fig. 3 shows how the request is made for the accessing
critical region. Initially it is assumed that all the queues of each
critical region are empty. So, there is no request made by
existing processes in the parallel computing. When request is
made to access critical region, at that time request goes to
queue for that critical region. If it is found empty, then that
process can use that critical region for the period of time set by
that process only. One more assumption is made that each and
every tasks for the processes have pre-calculated time for the
use of critical region. While entering the critical region by a
requesting process, it must be filled the duration of the use of
critical region. That is how the time stamp concept comes in to
the picture. Suppose that process fails or stop executing its
instructions or lines of code in the critical region. At such
moments, no other process can access that critical region until
current process exits that critical region. If we have certain
time limit for the use of that critical region, we can calculate
time and make that process exit from that critical region.
Therefore, this allows other waiting processes to use that
critical region for further executing the lines of code.
Algorithm 1:
Shared Variables/Critical Region: CR
For processes i=0 to N
do
{
// Process Non Critical Regions
.
.
// End of Non Critical Regions
Request_CR (i);
// if Request Granted then Enter CR else wait
Exit_CR (i);
}while(1);
This is the basic algorithm for the processes which shows
gene
ral procedure for the accessing critical region. Now our
proposed algorithm is consist of time stamp which ensure the
failure recovery of the process in the critical region.
Algorithm 2:
Shared Variables/Critical region: CR
CT: Current Time of the system
DUR: Duration of use of Critical Region
CT
first
:
First Previously Requested Process Current Time
DUR
prev
: All Previously Requested Process Duration of use of Critical
Region
For processes i=0 to N
Do
{
// Process Non Critical Regions
.
.
// End of Non Critical Regions
Request_CR (i,CT,DUR);
If(Queue of CR is Empty)
Enter Critical Region
Else
{
If(CT = CT
first
+ DUR
prev
)
{
Send Message to Currently Accessing Process
If(reply = true)
Update DUR
prev
with new Time
Else
Remove current process entry from the queue
}
Wait for Critical Region to be free until DUR
}
Exit_CR (i);
}while(1);
In our proposed algorithm, we assumed that initially all the
queues
are empty. And all processes share common time and it
is synchronized with time at every moment of time. When
process finds that the critical region which it wants to access or
Process A
LOCK
Free Not Free
Wait for free
Set Lock
Enter
F
i
g
. 1. Scenario of entering critical region by a process
Process A
Inside Critical Region
Exit critical region and set lock free
AND notify other waiting process
Fig. 2. Scenario of exiting critical region by a process

use is not free. That means another process is already in the
cri
tical region, in such scenario, the requesting process will
enter its current time of the request time and the duration of
time of the use of the critical region in the queue of that critical
region with its own unique id. When currently residing process
exit from the critical region, it removes its entry from the
queue. Then and then next process can enter that critical
region. In the case of the failure, the process sends one
message to the currently residing process in the critical region,
and if reply from the that residing process comes positive then
that process simply updates its duration of time in the queue
and if it fails to reply then the next process removes currently
residing process entry from the queue as it is assumed that
process is dead within the critical region. Thus, failure of the
process can be recovered from the critical region.
Fig. 4 shows three main elements of request. First is Process
ID, which is most important part of the request. It says which
process has made that request. Second part is Time of Request,
which is kind of little mathematical step in the request. It
calculates total time that requesting process has to wait to
access that particular critical region. That is addition of
previous request’s Time of Request with its Duration of Use,
which is third term or elements of the request. It simply shows
that how long that requesting process takes time to use the
particular critical region.
4. ANALYTICAL MODEL AND PERFORMANCE
EVALUATION
Assume that the average duration of use is U simulation time
(wall clock time). This shows that until U simulation time
another requesting process has to wait for the utilization of that
particular critical region. Thus, all requesting process present
in the queue of that critical region has to wait with the number
of request present before it. For (N+1)
th
requesting process,
wait time for accessing critical region is Total
wait
,
wait
Total U N
= ×
(1)
In (1),
U is average time of use of the critical region. But in
present, U can be calculated as below:
1
n
wait i
i
Total D
=
=
∑
(2)
whe
re D in (2) represents the duration of use of each request
present in the queue of critical region. Therefore, wait time to
access that critical region for N+1 requesting process is now as
per equation (2). Worse case for that is if any process takes
more time than it has been declared in the request then each
process has delayed time to access that critical region. Suppose
delay time is denoted by X. Now it can be said that for the N+1
requesting process actual wait time is as below:
1
n
wait i
i
Total D X
=
= +
∑
(3)
In (3), since X is calculated every simulation time, the wait
time is dynamically increase if more than one processes take
more time to access critical region. Every delay is notified to
each requesting processes present in the queue by passing a
message. So, messages passed to other requesting processes
are directly proportional to the occurrence of delay. Each time
N message is passed when delay is occurred for N+1
requesting process present in the queue. After getting message
containing delay time, all requesting processes, update their
wait time by adding delay in to the wait time. Table I and Fig.
5 present the numerical and simulation results, respectively.
Case 1: All N requesting processes has constant same time of
delay when N+1 requesting processes present in the critical
region queue.
Let say, every N processes has delay of X with addition to
their duration of use of critical region. Now for N+1 process,
wait time is calculated as below:
( )
1
( 1) 2
n
wai
t i
i
Total D X N N
=
= + −
∑
(4)
In this case, it is assumed that constant equal time of delay
has been occurred by each N processes present in the queue of
critical region.
Process A
Enter Process ID, Current Time
of Request, and Duration of USE
in Critical Region’s Queue
Queue
Empty?
Enter CR
CT =
CT
first
+DUR
prev
Wait
Send Msg to Current
Using process
Reply
Update DUR
prev
Remove Current using
process from the Queue
and Set CR Free
Fig
3. Flowchart of Requesting CR
Process ID Time of Request Duration of Use
Fig4. Data Structure of Request for the CRs

Case 2: Irregular time of delay occurred at each N r
equesting
processes present in the critical region’s queue.
Suppose each requesting process has different values of X.
This implies that each process has different time of delay than
the others. Based on this, the delay time for N+1 requesting
process can be approximated in (5):
1 1
n n
wait i i
i i
Total D X
= =
=
+
∑ ∑
(5)
C
as
e
3: Number of messages passed to synchronize wait time
for each N requesting process.
Each time delay occurred, a message is passed to rest of
requesting processes present in the queue of critical region. So
messages passed to synchronize wait time should not be more
than N messages, considering there is delay in only one
requesting process which is currently accessing critical region.
Likewise, considering two different cases that every requesting
processes has delay and few requesting processes has delay,
we get two different equation for the number of messages
passed to synchronize the wait time for N+1 requesting process
to access that critical region. Total messages passed in the case
of every requesting processes have delay is almost same as the
total wait time for the N+1 requesting process when all N
processes have delay. Equation for the total number of
message passed for synchronization is as below:
(
)
1 2
MSG
Tot
al N N= − (6)
And for the second case, it depends upon the number of
requesting processes which are behind the currently accessing
process and also it depends upon the location of process which
has delay in the queue, though it can be calculated with a
condition of occurrence of delay with the processes.
1
N
MSG
i
Total N
=
=
∑
if N has delay (7)
Number of messages passed to synchronize wait time is
directly proportional to the number of requests present in the
queue of critical region. So, it is clear that larger request
present in the queue will have more affect in the wait time for
the coming request. It should be noted in Table I that every
processes has delayed and number of messages passed to
synchronize wait time for other processes present in the queue
of critical region.
5. CONCLUSION
According to our algorithm, we can assure all those three
mutual exclusion condition or properties. But outcome of the
parallel computing may have inappropriate result, which may
be wrong in actual. So, we can’t say that our solution is
effective and appropriate in all the cases of parallel computing.
But there may be one or two cases when our solution is
effective like when there is no need to use of value or
information of the critical region in the next request. Our
algorithm tries to maintain mutual exclusion properties in
addition to that; we have recovery from the failure of process
in the critical region.
REFERENCES
[1] S. Dandamudi, “Performance Implications of Task Routing and Task
Scheduling Strategies for Multiprocessor Systems”, In Proceedings of the
IEEE-Euromicro Conference on Massively Parallel Computing Systems,
IEEE Computer Society, Ischia, Italy, May 2-6, 1994, pp. 348-353.
[2] S. Dandamudi, “The effect of Scheduling Discipline on Dynamic Load
Sharing in Heterogeneous Distributed Systems”, In Proceedings of the
5th International Workshop on Modeling, Analysis, and Simulation of
Computer and Telecommunication Systems (MASCOTS ’97), IEEE
Computer Society, Haifa, Israel, January 12-15, 1997, pp. 17-24.
[3] Hiran Ramankutty , Interprocess Communication part-1, Issue 104 of
Linux Gazette, July 2004. http://linuxgazette.net/104/ramankutty.html
[4] H
iran Ramankutty , Interprocess Communication part-1, Issue 105 of
Linux Gazette, July 2004 http://linuxgazette.net/105/ramankutty.html
[5] M
.Sasikumar, Dinesh Shikhare And P. Ravi Prakash, Introduction to
Parallel Processing, pp 70-74.
[6] Eisuke Yoshida, Hirotsugu Kakugawa, A Learning System for the
Problem of Mutual Exclusion in Multithreaded Programming.
[7] Xiaodong Zhang, Yong Yan, and Robert Castaneda, Evaluating and
Designing software Mutual Exclusion Algorithms on Shared Memory
Multiprocessors.
[8] Ranganath Atreya, Neeraj Mittal, A Quorum-Based Group Mutual
Exclusion Algorithm for a Distributed System with Dynamic Group Set
Table I: Average time of use and Number of request in the queue present
Number of Request in the Queue
Average Use of Critical Region
1 2 3 4 5 6 7 8 9 10
1 1 2 3 4 5 6 7 8 9 10
2 2 4 6 8 10 12 14 16 18 20
3 3 6 9 12 15 18 21 24 27 30
4 4 8 12 16 20 24 28 32 36 40
5 5 10 15 20 25 30 35 40 45 50
6 6 12 18 24 30 36 42 48 54 60
7 7 14 21 28 35 42 49 56 63 70
8 8 16 24 32 40 48 56 64 72 80
9 9 18 27 36 45 54 63 72 81 90
10 10 20 30 40 50 60 70 80 90 100
Fig
ure 5.
Every Processes has Delayed and Number of messages passed to
synchronize
wait time for other processes present in the queue of critical
region