Slides For Chapter 7: Opera3ng System Support

Slides for Chapter 7:

Opera3ng System support
From Coulouris, Dollimore, Kindberg and

Blair
Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Learning objec3ves
•  Know what a modern opera3ng system does to
support distributed applica3ons and middleware
–  Defini3on of network OS
–  Defini3on of distributed OS
•  Understand the relevant abstrac3ons and
techniques, focussing on:
–  processes, threads, ports and support for invoca3on
mechanisms.
•  Understand the op3ons for opera3ng system
architecture
–  monolithic and micro-‐kernels
2 *
System layers
Applications, services
Middleware
OS: kernel, OS1 OS2

libraries & Processes, threads, Processes, threads,
servers communication, ... communication, ...
Platform
Computer & Computer &

network hardware network hardware
Node 1 Node 2
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Educa3on 2012
Middleware and the Opera3ng System
•  Middleware implements abstrac3ons that support network-‐wide
programming. Examples:
•  RPC and RMI (Sun RPC, Corba, Java RMI)
•  event distribu3on and filtering (Corba Event No3fica3on, Elvin)
•  resource discovery for mobile and ubiquitous compu3ng
•  support for mul3media streaming
•  Tradi3onal OS's (e.g. early Unix, Windows 3.0)
–  simplify, protect and op3mize the use of local resources
•  Network OS's (e.g. Mach, modern UNIX, Windows

NT)
–  do the same but they also support a wide range of communica3on standards
and enable remote processes to access (some) local resources (e.g. files).
4
*
Networked OS to Distributed OS
•  Distributed OS
–  Presents users (and applica3ons) with an integrated
compu3ng plaaorm that hides the individual computers.
–  Has control over all of the nodes (computers) in the
network and allocates their resources to tasks without
user involvement.
•  In a distributed OS, the user doesn't know (or care) where his
programs are running.
–  One OS managing resources on mul3ple machines
–  Examples:
•  Cluster computer systems
•  Amoeba, V system, Sprite, Globe OS
5
The support required by middleware
and distributed applica3ons
•  OS manages the basic resources of computer
systems
•  Tasks:
–  programming interface for these resources:
•  abstrac3ons such as: processes, virtual memory, files,
communica3on channels
•  Protec3on of the resources used by applica3ons
•  Concurrent processing
–  provide the resources needed for (distributed) services
and applica3ons:
•  Communica3on -‐ network access
•  Processing -‐ processors scheduled at the relevant computers
6 *
Core OS func3onality
Process manager
Communication
manager
Thread manager Memory manager
Supervisor
Protec3on:
•  Why does the kernel need to be protected?
•  Kernels and protec3on
–  kernel has all privileges for the physical resources, processor, memory..
•  execu3on mode
–  kernel and user
•  address space
–  kernel and user
•  user transferred to kernel
-‐ system call trap
•  try to invoke kernel resources
•  switch to kernel mode
•  cost
–  switching overhead to provide protec3on
8
Processes and Threads (1)
•  process has one environment
•  thread: ac3vity, "thread" of execu3on in one environment
•  execu3on environment:
–  an address space
–  synchroniza3on and communica3on resources
–  i/o resources
•  why execu3on environment?
•  threads share one execu3on environment, why?
•  older names: heavyweight and lightweight processes
•  Address space
9
•  Address space
–  unit of management of a process' virtual memory
•  Regions
–  Text, heap, stack
•  Each region
–  beginning virtual address and size
–  read/write/exe permissions for the process' threads
–  growth direc3on
•  Why regions:
–  different func3onali3es, for example:
•  different stack regions for threads
•  memory-‐mapped file
•  Shared memory regions among processes?
–  libraries
–  kernel
–  data sharing and communica3on
10
Address space
Figure 7.3
2N
Auxiliary
regions
Stack
Heap
Text
0
Processes and Threads (4): process
• 
crea3on
Distributed OS
–  choice of target host
–  actual crea3on of execu3on env
•  choice of target host
–  transfer policy: local or remote?
–  loca3on policy: if not local, which host/processor
•  V and Sprite system: user has a command and OS chooses
•  Amoeba: a run server decides, more transparent
•  sta3c and adap3ve loca3on policies
–  sta3c: predetermined func3on
–  adap3ve: depends on current state of the processing nodes
•  load-‐sharing systems
–  centralized: one load manager
–  hierarchical: tree of managers
–  decentralized: nodes exchange informa3on, local decision
–  sender-‐ini3ated
–  receiver-‐ini3ated
•  process migra3on
–  moved while it's running
–  what need to be sent?
12
•  crea3ng an execu3on env
–  address space with ini3al contents
–  ini3aliza3on
•  staBcally defined format from a list of regions
•  derived from an exisBng exe env
–  fork in unix
–  derived from the parent
–  shares the text region
–  a copy of the heap and stack
–  copy-‐on-‐write
13
Copy-‐on-‐write
Figure 7.4 Process A’s address space Process B’s address space
RB copied
from RA
RA RB
Kernel
Shared
frame
A's page B's page
table table
a) Before write b) After write
Processes and Threads (7): Thread
memory regions
Process
Thread activations
Activation stacks
(parameters, local variables)
Heap (dynamic storage, 'text' (program code)

objects, global variables)
system-provided resources
(sockets, windows, open files)
15 *
Client and server with threads
Figure 7.5

Thread 2 makes
requests to server
Receipt & Input-output
Thread 1 queuing
generates
results
T1
Requests
N threads
Client
Server
•  average interval of successive job comple3ons
–  one request: 2 milliseconds of processing and 8 for i/o
delay
–  one thread: 2+8 = 10 milliseconds, 100 requests/second

–  two threads: 125 requests/second, serial i/o, why?
–  two threads: 200 requests/second, concurrent i/o, why?
–  two threads with cache (75% hit):
•  2 milliseconds (.75*0 + .25*8), 500 requests/sec
–  cpu overhead of caching: 2.5 milliseconds, 400 requests/
sec
17
Alterna3ve server threading
architectures
Figure 7.6

per-connection threads per-object threads
workers
I/O I/O remote

remote remote
objects objects
objects
a. Thread-per-request b. Thread-per-connection c. Thread-per-object
Processes and Threads (10): server threading architectures
server server server

process workers process per-connection threads process per-object threads
I/O I/O remote

remote remote
objects objects
objects
a. Thread-per-request b. Thread-per-connection c. Thread-per-object

–  Implemented by the server-‐side ORB in CORBA
(a)  would be useful for UDP-‐based service, e.g. NTP (network 3me protocol)
(b)  is the most commonly used -‐ matches the TCP connec3on model
(c)  is used where the service is encapsulated as an object. E.g. could have mul3ple
shared whiteboards with one thread each. Each object has only one thread,
avoiding the need for thread synchroniza3on within objects.
19 *
Processes and Threads (11):
Threads vs processes
•  Crea3ng a thread is (much) cheaper than a process (~10-‐20 3mes)
•  Switching to a different thread in same process is (much) cheaper (5-‐50 3mes)
•  Threads within same process can share data and other resources more
conveniently and efficiently (without copying or messages)
•  Threads within a process are not protected from each other
Figure 6.7 State associated with execution environments and threads

ExecuBon environment Thread
Address space tables Saved processor registers
Communica3on interfaces, open files Priority and execu3on state (such as
BLOCKED )
Semaphores, other synchroniza3on Sopware interrupt handling informa3on
objects
List of thread iden3fiers Execu3on environment iden3fier
Pages of address space resident in memory; hardware cache entries
20 *
Concurrency
•  Issues in concurrency:
–  Race condi3on
–  Deadlock
–  Starva3on
•  Programming support
–  library (POSIX pthreads)
–  language support (Ada95, Modula-‐3, Java)

21
•  thread (process) execu3on
–  create/fork
–  exit
–  join/wait
–  yield
22
•  Synchroniza3on
–  coordinate current tasks and prevent race condi3ons
on shared objects
–  Cri3cal region: only one thread/process at a 3me is
allowed
–  Why cri3cal regions should be as small as possible?

•  Programming support
–  Mutual exclusion
–  Condi3on Variables
–  Semaphores
23
Processes and Threads (15): Mutual
Exclusion
•  Mutual exclusion (mutex)
–  cri3cal region/sec3on
–  before entering cri3cal region, try to lock
–  mutex_lock(l):
•  if try to lock is successful
–  lock and con3nue
•  else
–  blocked
–  mutex_unlock(l): release the lock
24
•  One producer, one consumer, producer can produce many items
(1P1CinfD)
•  How about nPnCinfD ?
Producer Consumer
mutex_lock(D) mutex_lock(D)
while (no data) // count <= 0
mutex_unlock(D)
sleep (how long? spin poll)
mutex_lock(D)
produce one item consume one item
mutex_unlock(D) mutex_unlock(D)
25
Processes and Threads (17): Condi3on
Variables
•  Condi3on variable
–  wait for an event (condi3on) before proceeding
–  Assoicated mutex with the condi3on
•  Wai3ng for an event
1.  lock associated mutex m
2.  while (predicate is not true) // "if" could work, but less safe
3.  cv_wait( c, m )
4.  do work
5.  unlock associated mutex m
•  Signaling an event
1.  lock associated mutex m
2.  set predicate to true
3.  cv_signal( c ) // signal condi3on variable (wake-‐up one or all)
26
•  cv_wait(c, m):
2.  block thread
3.  put it on the queue to wait for a signal
4.  lock associated mutex m // why?
•  cv_signal(c):
–  wake up a thread wai3ng on the condi3on
27
Producer Consumer
mutex_lock(D) mutex_lock(D)
while (no data)
cv_wait(yesD, D)
cv_signal(yesD)
mutex_unlock(D) mutex_unlock(D)
28
Semaphores
•  binary semaphores = mutex
•  coun3ng/integer semaphores
–  P(s) [prolagen -‐-‐ decrease (Dutch)]
•  if s > 0
–  decrement s
•  else
–  blocked
–  V(s) [verhogen -‐-‐ increase]
•  increment s
29
Processes and Threads (21): first try
Producer Consumer
D=1 //initialization
P(D) P(D)
while (no data)
V(D)
sleep
P(D)
V(D) V(D)
•  Does this work?
•  What are basically P and V used for?
30
Producer
1P1CinfD (nPnCinfD)
Consumer
D=1 // cri3cal region
Count=0 // # of items

P(Count)
P(D) P(D) // mutex; binary semaphore
V(D) V(D)
V(Count)

P(Count)
V(Count)
V(D) V(D)

P(Count)
V(Count)
V(D) V(D)
31
•  Versions 1 and 2 work
–  Version 1 has more concurrency
•  Versions 3 doesn’t work
•  Exercises
–  One producer, one consumer, one data item
(1P1C1D) [lock steps, PCPC...]
–  One producer, one consumer, up to n data items
(1P1CnD) same for nPnCnD
32
•  What could happen here?
mutex_lock(B) mutex_lock(A)
mutex_lock(A) mutex_lock(B)
do work do work
mutex_unlock(B) mutex_unlock(A)
mutex_unlock(A) mutex_unlock(B)
•  How to prevent the problem?
33
Scheduling
•  Preemp3ve
–  a thread can be suspended at any point for
another thread to run
•  Non-‐preemp3ve
–  a thread can only be suspended when it de-‐
schedules itself (e.g. blocked by I/O, sync...)
[cri3cal region between calls that de-‐schedule]
34
Processes and Threads (26): Thread
Implementa3on
•  Kernel-‐level
–  Win NT, Solaris, Mach, Chorus
–  Kernel schedules threads
•  User-‐level
–  library based (pthreads, or in the language like java)
–  run-‐3me system in user space manages threads
–  Kernel schedules processes
•  Disadvantages of user-‐level threads
–  can't take advantage of mul3processors
–  one thread is blocked because of a page fault, the process is blocked, all the
others threads in the same process are blocked
–  threads in different processes aren't scheduled in the same environment
•  Advantages of user-‐level threads
–  less costly to manage
–  scheduling can be customized
–  more user-‐level threads can be supported
35
•  Mixed
–  Mach:
•  user-‐level code to provide scheduling hints to the
kernel
–  Solaris:
•  assign each user-‐level thread to a kernel-‐level thread
(mul3ple user threads can be in one kernel thread)
•  crea3on/switching at the user level
•  scheduling at the kernel level
36
•  FastThread package
–  hierarchical, event-‐based scheduling
–  each process has a user-‐level thread scheduler
–  virtual processors are allocated to processes
•  the # of virtual processors depends on a process's needs
•  physical processors are assigned to virtual processors
•  virtual processors can be dynamically allocated and
deallocated to a process according to its needs.
–  Scheduler Ac3va3on (SA)
•  event/call from kernel to user-‐level scheduler
•  represents a !me slice on a virtual processor (# of SA's < #
of virtual processors)
•  user-‐level scheduler can assign threads to SA's (3me slices).
37
•  Events from user-‐level scheduler to kernel
–  P idle: virtual processor is idle
–  P needed: new virtual processor needed
•  Events from kernel to user-‐level scheduler
–  virtual processor allocated (P added):
–  User-‐level: scheduler can choose a ready thread to run
–  SA blocked (in kernel):
–  Kernel: sends a new SA
–  User-‐level: a ready thread is assigned to the new SA to run
–  SA unblocked (in kernel):
–  user-‐level: thread is back on the ready queue
–  kernel: allocate new virtual processor to process or preempt another SA
–  SA preempted (in kernel):
–  user-‐level: puts the thread back to the ready queue
38
Scheduler ac3va3ons
Figure 7.10

P added
Process Process
A B SA preempted
Process SA unblocked
SA blocked
Kernel
P idle
Virtual processors Kernel
P needed
A. Assignment of virtual processors B. Events between user-level scheduler & kernel

to processes Key: P = processor; SA = scheduler activation
Invoca3ons between address spaces
Figure 7.11 (a) System call Thread Control transfer via
trap instruction

Control transfer via
privileged instructions
User Kernel
Protection domain
(b) RPC/RMI (within one computer) boundary
Thread 1 Thread 2
User 1 Kernel User 2

(c) RPC/RMI (between computers)
Thread 1 Network Thread 2
User 1 User 2
Kernel 1 Kernel 2
RPC delay against parameter size
Figure 7.12 RPC delay

Requested data
size (bytes)
0 1000 2000
Packet
size
A lightweight remote procedure call
Figure 7.13

Client Server
A stack
A
1. Copy args 4. Execute procedure

and copy results
User stub stub
Kernel
2. Trap to Kernel 3. Upcall 5. Return (trap)
Times for serialized and concurrent
invoca3ons
Serialised invocations Concurrent invocations
Figure 7.14
process args process args
marshal marshal
Send transmission Send
process args
marshal
Receive Send Receive
unmarshal unmarshal
execute request execute request
marshal marshal
Send Send
Receive
unmarshal
Receive Receive execute request
unmarshal unmarshal marshal
process results process results Send
process args
marshal Receive
Send
unmarshal
process results
Receive time
unmarshal
execute request
marshal
Send
Receive
unmarshal
process results
Client Server Client Server
Monolithic kernel and microkernel
Figure 7.15

S4 .......
S1 S2 S3 S4 .......
.......
S1 S2 S3
Monolithic Kernel Microkernel

Key:
Server: Kernel code and data: Dynamically loaded server program:
The role of the microkernel
Figure 7.16

Middleware
Language Language OS emulation

support support subsystem
....
subsystem subsystem
Microkernel
Hardware
The microkernel supports middleware via subsystems
Figure 7.17
The architecture of Xen
46 Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
46
Use of rings of privilege
Figure 7.18

47
Virtualiza3on of memory management
Figure 7.19

48
Split device drivers
Figure 7.20

49
I/O rings
Figure 7.21

50
The XenoServer Open Plaaorm
Architecture
Figure 7.22

51
Summary
•  Network OS vs. Distributed OS
•  Process vs. Thread
•  Mutual Exclusion vs. Condi3on Variables vs.
Semaphores
•  Preemp3ve vs. Non-‐preemp3ve
•  Monolithic kernel vs. Microkernel
•  OS Virtualiza3on

Slides For Chapter 7: Opera3ng System Support

Uploaded by

Document Information

Original Title

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

Slides For Chapter 7: Opera3ng System Support

Uploaded by

Copyright:

Available Formats

Slides for Chapter 7:

From Coulouris, Dollimore, Kindberg and

OS: kernel, OS1 OS2

Computer & Computer &

• Network OS's (e.g. Mach, modern UNIX, Windows

Thread manager Memory manager

a) Before write b) After write

Heap (dynamic storage, 'text' (program code)

I/O I/O remote

a. Thread-per-request b. Thread-per-connection c. Thread-per-object

server server server

I/O I/O remote

a. Thread-per-request b. Thread-per-connection c. Thread-per-object

Figure 6.7 State associated with execution environments and threads

A. Assignment of virtual processors B. Events between user-level scheduler & kernel

User 1 Kernel User 2

Thread 1 Network Thread 2

1. Copy args 4. Execute procedure

User stub stub

Monolithic Kernel Microkernel

Server: Kernel code and data: Dynamically loaded server program:

Language Language OS emulation

The microkernel supports middleware via subsystems

You might also like

•  Network OS's (e.g. Mach, modern UNIX, Windows