Download Concurrent processes and programming

T. Seidmann
Distributed Operating Systems
Concurrent processes and programming
• Processes are programs in execution
• Sequential process: contains single thread of execution
• Concurrent process: simultaneous interacting sequential
processes (asynchronous, each has its own address space)
- heavy weight processes
• Process may spawn new processes (subprocesses)
• When process and subprocess share a common address space,
but each has its local state: light-weight processes, threads
PCB
PCB
TCB
Two-level
concurrencyconcept of
a process
and a thread
thread
thread
TCB
thread
TCB
thread
Thread run-time library support
Native OS
1
T. Seidmann
Distributed Operating Systems
Thread applications
Terminal server
-
thread
File server
MAIN
Q
QQ
s
-
Client
thread
-
thread
-
-buffer-
thread
WRITE READ
-
thread
3
Identical static
Dynamic threads
Concurrent and
threads
with dispatcher
asynchronous
requests
Thread implementation - user space
Examples of user-space implementation:
• DCE threads (Open Group, former OSF)
• 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
2
T. Seidmann
Distributed Operating Systems
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
• 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).
3
T. Seidmann
Distributed Operating Systems
Heavy-weight process
Heavy-weight process
User-space
threads
Three-level
concurrency
B
B of a preemptive B multithreaded
LWP
kernel
(Sun solaris)
B
A
B B A A LWP
LWP
E
E
E
E
A
A A LWP
Light-weight
processes
Kernel-space
threads
SMP - system
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
4
T. Seidmann
Distributed Operating Systems
#
"!
Precedence
J
J#
#
^
J
relations
#
#
"!"!
@
@
@
@ #
?
?
#
R
@
Communication"!
"!
#
#
"!"!
J
J#
^
J
"!
@
@ #
@
@
"!
channels
"!
"!
Synchronous process
Asynchronous process
graph (DAG)
graph
P1
P2
SPACE
C A
C A
CW A
A
P3
-
AUA
P4
TIME
C
C
C
SC
SC
CW S
w
-
-
-
: communication
: events
Time-space model for interacting processes
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
5
T. Seidmann
Distributed Operating Systems
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
Logical communication
Request
-
CLIENT
Reply
SERVER
6
?
Kernel
6
Actual
communication
Network
?
Kernel
• Service-oriented communication model
• Higher-level abstraction of IPC than RPC or message passing
communication
Client and server communication
RPC
communication
Message-passing
communication
Connection-oriented of connectionless
transport service
6
T. Seidmann
Distributed Operating Systems
• Standard horizontal or vertical partitioning of modules can be
applied to the structure of servers
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 different ways:
– When an event occurs
– How long it takes
– Which event occurs first
• 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
Distributed time service
#
-
External
UTC sources
-
TS
#
#
-
TS
"!
"!
>
I# @
@
R
=
TS
Time
"!
servers
-
TC
Client
time clerks
"!
#
-
TC
"!
7
T. Seidmann
Distributed Operating Systems
• 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
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. Lamport’s logical
clock is a fundamental concept for ordering of processes and
events in distributed systems.
•
•
•
•
Each process Pi in the system maintains a logical clock Ci
→: 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
8
T. Seidmann
Distributed Operating Systems
• Processes interact with each other using a pair of send and
receive operations: these are considered events as well
Rules for Lamport’s logical clock:
1. if a → b within the same process then C(a) < C(b)
2. If a is the sending event of Pi and b is the corresponding
receiving event of Pj then Ci(a) < Cj (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. Cj (b) = max(T Sa + d, Cj (b)), T Sa 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:
9
T. Seidmann
Distributed Operating Systems
3. For all events a and b, C(a) 6= C(b) (this must be fulfilled
only for disjoint events)
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:
Ci(a) < Cj (b) doesn’t imply a → b, i.e. we cannot distinguish
disjoint events using values of logical clocks.
Vector logical clocks
For every event a process Pi maintains the vector V Ci(a) =
[T S1, T S2, . . . , Ci(a), . . . , T Sn], where n is the number of
cooperating processes, Ci(a) ≡ T Si is the logical clock for
event a at Pi and T Sk is the best estimate of the logical clock
time for process Pk obtained through the timestamp information
carried by messages in the system.
• V Ci is initialized to zero vector at system startup
• The logical clock within a process is incremented according to
rule 1
• Rule 2 is modified: When sending message m from Pi
(event a) to Pj , the logical timestamp V Ci(m) is sent
along with m to Pj . Let b be the event of receiving m at
10
T. Seidmann
Distributed Operating Systems
Pj . Pj updates its logical clock vector V Cj (b) such that
T Sk (b) = max(T Sk (a), T Sk (b)) for every k = 1 . . . n
and also increments its logical clock according the original rule
2.
The vector logical clock allows for identification of disjoint
events, because it is not possible to have V Ci(a) < V Cj (b)
unless a → b.
a,100
b,300
200
d,010
S
S
S
S
S
S
220
g,001
450
c,550
e,230 240
f,260
@
250
@
@
@
@
@
242
h,243
274
244
Causally related events: (a, e, h)
Disjoint events: (b, f)
11