Concurrent Processes and Programming: T. Seidmann Distributed Operating Systems
Concurrent Processes and Programming: T. Seidmann Distributed Operating Systems
`
`
`
thread
thread
thread
thread
thread
MAIN
WRITE READ
Terminal server File server Client
Identical static
threads
Dynamic threads
with dispatcher
Concurrent and
asynchronous
requests
Thread implementation - user space
Examples of user-space implementation:
DCE threads (Open Group, former OSF)
3
T. Seidmann Distributed Operating Systems
Sun LWP package, green threads (Java)
MIT pthreads
Threads run in top of a run-time support library
A blocking system call from an executing thread is not trapped by the OS but is routed
to the run-time procedure
Context-switching requires very little overhead
Primitives of a typical thread package:
1. Thread management (creation, suspension, termination)
2. Assignment of priority and other thread attributes
3. Synchronization and communication support (semaphores, monitors, message passing)
Thread implementation - kernel space
Blocking and scheduling are no problem
4
T. Seidmann Distributed Operating Systems
No portability, no two-level concurrency abstraction
supported by the proliferation of symmetric multiprocessor (SMP) machines
Kernel- and user-space thread implementation can be combined: hybrid thread
implementation; examples are Sun Solaris and Linux (LinuxThreads, NGPT, NPTL).
5
T. Seidmann Distributed Operating Systems
(Sun solaris)
`
`
`
`
`
`
/
/
/
`
`
`
`
`
`
/
/
/
'
'
'
'
'
'
'
'
Heavy-weight process Heavy-weight process
LWP LWP LWP LWP
SMP - system
User-space
threads
processes
Light-weight
Kernel-space
threads
of a preemptive
concurrency
Three-level
multithreaded
kernel
Graph models for process representation
Processes are related by their need for synchronization and/or communication
A special case of synchronization is the precedence relationship between processes
6
T. Seidmann Distributed Operating Systems
Time-space model for interacting processes
"!
#
"!
#
"!
#
"!
#
"!
#
"!
#
"!
#
"!
#
"!
#
"!
#
`
`
`
-
`
`
`
\
\
\
`
`
`
`
`
`
\
\
\
\
\
\
`
`
` /
/
/
/
/
/
/
/
/`
channels
Communication
Precedence relations
Synchronous process
graph (DAG)
Asynchronous process
graph
: communication
: events
P1
P2
P3
P4
SPACE
TIME
"!
#
7
T. Seidmann Distributed Operating Systems
Expression of interaction of processes can be done by taking an existing sequential
language and extending it with (for example):
cobegin/coend, fork/join - master/slave or parent/child relationship;
implementation of the precedence process graph model
Peer-to-peer relationship among processes with message passing; implementation of the
communication process path
The client/server model
Interaction through a sequence of requests and responses
8
T. Seidmann Distributed Operating Systems
Logical communication
CLIENT SERVER
Kernel Kernel
Request
Reply
Actual
communication
Network
Service-oriented communication model
Higher-level abstraction of IPC than RPC or message passing communication
transport service
Client and server communication
Message-passing
communication
RPC
communication
Connection-oriented of connectionless
Standard horizontal or vertical partitioning of modules can be applied to the structure
of servers
9
T. Seidmann Distributed Operating Systems
Time services
Clocks are used to represent time (a relative measure of a point of time) and timer
(an absolute measure of a time interval); it is used to describe the occurence of events
in three dierent ways:
When an event occurs
How long it takes
Which event occurs rst
There is no global time in distributed systems
Physical clock: close approximation of real time (both point and interval)
Logical clock: preservers only the ordering of events
Physical clocks
10
T. Seidmann Distributed Operating Systems
TS
"!
#
"!
#
"!
#
"!
#
.
TS
TS
TC
TC
External
UTC sources
servers
Time
Distributed time service
Client
time clerks
"!
#
Compensating delay:
UTC sources to time servers
time servers to clients
Calibrating discrepancy
Application of physical clocks:
Protocols rely on a time-out for handling exceptions
Timestamping for secure internet communication (avoiding play back attacks)
Logical clocks
11
T. Seidmann Distributed Operating Systems
For many applications, events need not be scheduled or synchronized with respect to
the real-time clock; it is only the ordering of event execution that is of concern. Lamports
logical clock is a fundamental concept for ordering of processes and events in distributed
systems.
Each process P
i
in the system maintains a logical clock C
i
: happens-before relation to synchronize the logical clock
a b: Event a precedes event b
Within a process, if event a precedes event b, then C(a) < C(b)
The logical clock in a process is always incremented by an arbitrary positive number
when events in the process progress
Processes interact with each other using a pair of send and receive operations: these
are considered events as well
Rules for Lamports logical clock:
1. if a b within the same process then C(a) < C(b)
12
T. Seidmann Distributed Operating Systems
2. If a is the sending event of P
i
and b is the corresponding receiving event of P
j
then
C
i
(a) < C
j
(b) (can be enforced if the sending process timestamps its logical clock in
the message and receiving process updates its logical clock using the larger of its own
clock time and the incremented time stamp)
Implementation of the rules:
1. C(b) = C(a) + d
2. C
j
(b) = max(TS
a
+ d, C
j
(b)), TS
a
is the timestamp of the sending event
The happens-before relation describes the causality between two events; it is transitive.
Two events, a and b, are said to be disjoint events and can be run concurrently if neither
a b nor b a.
Rules 1 and 2 result in partial ordering, so a third rule can be added:
3. For all events a and b, C(a) = C(b) (this must be fullled only for disjoint events)
13
T. Seidmann Distributed Operating Systems
System-wide unique logical clock times for all events can be obtained by concatenating
the logical clock with a distinct process ID number.
The happens-before relation has an important property: C
i
(a) < C
j
(b) doesnt
imply a b, i.e. we cannot distinguish disjoint events using values of logical clocks.
Vector logical clocks
For every event a process P
i
maintains the vector V C
i
(a) =
[TS
1
, TS
2
, . . . , C
i
(a), . . . , TS
n
], where n is the number of cooperating processes,
C
i
(a) TS
i
is the logical clock for event a at P
i
and TS
k
is the best estimate of the
logical clock time for process P
k
obtained through the timestamp information carried by
messages in the system.
V C
i
is initialized to zero vector at system startup
The logical clock within a process is incremented according to rule 1
Rule 2 is modied: When sending message m from P
i
(event a) to P
j
, the
logical timestamp V C
i
(m) is sent along with m to P
j
. Let b be the event
14
T. Seidmann Distributed Operating Systems
of receiving m at P
j
. P
j
updates its logical clock vector V C
j
(b) such that
TS
k
(b) = max(TS
k
(a), TS
k
(b)) for every k = 1 . . . n and also increments its
logical clock according the original rule 2.
The vector logical clock allows for identication of disjoint events, because it is not
possible to have V C
i
(a) < V C
j
(b) unless a b.
Disjoint events: (b, f)
`
`
`
`
`
`
a,100 b,300
450
c,550
200
220 250
242 244
d,010 e,230
240
f,260
274
h,243 g,001
Causally related events: (a, e, h)
15