04-operating system support

7/31/2019 04-Operating System Support

1/59

Verteilte Systeme

(Distributed Systems)

Karl M. [email protected]

http://www.infosys.tuwien.ac.at/teaching/courses/VerteilteSysteme/


2/59

Lecture 4:

Operating System Support

Processes and Threads

Client/Server Support and Concurrency

Object Server Issues

Code Migration

Virtualization


3/59

3

Processes and threads (1)

Unit of resource ownership and protection: Itprovides an address space to the program and

protects it from other (concurrent) processes Unit of dispatching: A process encapsulates a

program in execution - it contains the execution

state of the program and is the entity that isscheduled and dispatched by the OS

Enforced with hardware support (kernel mode)

High cost for allocation and switching (possiblyincluding swapping)

granularity not sufficient


4/59

5

Process Switching (non-distributed)

process B

Context switching as the result of IPC


5/59

6

Processes and threads (2)

Process remains the unit of resourcemanagement and protection, while thread

becomes the unit of dispatching (executionstate)

Within a process, threads provide concurrent

executions that share state (and the addressspace) minimal thread context (CPU,scheduling information, synchronization)

Protection, however, is left to the applicationdeveloper

Trade-off: Robustness vs. efficiency


6/59

7

Multi-threading (1)

A thread is an independent stream of execution

Different threads in the same process share a

global environment (e.g. same object instance)

The accesses of threads to shared resourcesmust be coordinated (synchronized)

Different threads may run on differentprocessors if available or share a single

processor Threads are provided by operating systems,

middleware, or even programming languages

Java provides support for threads


7/59

8

Multi-threading (2)

Threads are used to increase performance:

Parallelism on multiprocessor machines (more fine-

grained than processes) Multi-threading is often used to reduce the impact

of blocking operations (e.g. IO, networking) so that

communication and local processing can overlap Local communication cheaper (vs. IPC context

switching)


8/59

9

Multi-threading (3)

Threads are used to improve the structure of aprocess respectively a large program

Application-level parallelism Reactive (server) programming application

responds to incoming (client) events

Interactive (client) programming one thread torespond to user interaction, another to do thebackground work avoid blocking and increase

perceived speed Asynchronous (batch) processing (e.g.,

autobackup)


9/59

10

Multi-threading issues

Safety how to synchronize threads so thatthey do not interfere with one another

Liveness how to avoid deadlock situationsto ensure that all threads make progress(fairness?)

Performance Overhead (performancepenalty) from context-switching and

synchronization


10/59

11

User level threads

Thread library: routines for thread management, e.g.scheduling; saving and restoring thread context

The kernel is not aware of the existence of threads

All thread management done by the application:Cheap to create and destroy threads and only fewinstructions for switching, usually for synchronization

purpose (saves mode switches) Scheduling can be application specific

Can run on any OS

BUT: Kernel schedules process as a unit Blockingsystem call will block entire process (including allother threads)

BUT: Can not take advantage of multiprocessing


11/59

12

Kernel level threads (e.g., Windows)

Kernel maintains context information for theprocess and the threads: Thread management

is done by the kernel, only API to the kernelthread facility

Scheduling is done on a thread basis by the

kernel Multiprocessor support

Non-blocking

Kernel itself can be multithreaded BUT: Allocation and switching need expensive

system calls: mode switch to the kernel


12/59

13

User-Level vs. kernel-level Threads


13/59

14

Combined Approaches

Scheduler hints (Mach kernel)

Scheduler Activation: Kernel upcall to thread package(kernel calls the user-level scheduler), but violateslayered structure

Hybrid: lightweight processes (LWP; Solaris) Process includes the users address space, stack, and

process control block User level thread package: Thread creation done in the user

space, also the bulk of scheduling and synchronization ofthreads within application

User level threads are mapped onto kernel level threads:Lightweight processes (LWP)

Kernel threads (and LWPs) are scheduled by kernel: Thereis exactly one kernel thread for each LWP


14/59

15

Lightweight Process (1)


15/59

16


LWP exists within the process address space while atthe same time it is bound to a single dispatchable

kernel thread LWPs of one process share the user level thread table

within that process

Exploit concurrency application specific: Single threaded (no concurrency required)

Logical parallelism (structuring): Multithreaded without needfor hardware parallelism

Kernel parallelism for multiprocessing or non-blocking

Mixture: Background tasks may share LWP, while resourceaccess via single LWP.


16/59

17



17/59

Lecture 4:Operating System Support

Processes and Threads Client/Server Support and Concurrency


Code Migration

Virtualization


18/59


19/59

21

Client and server with threads

Common threads in a client: UI, processing,network connection

Common threads in a server: multiple clients;

multiple I/O

Server

N threads

Input-output

Client

Thread 2 makes

T1

Thread 1

requests to server

generatesresults

Requests

Receipt &

queuing


20/59

22

Multithreaded Client

Interact with human user and remote server inparallel (non blocking towards user)

Hide communication latencies: Do somethingelse in parallel (e.g. Web browser)

Load balancing (only useful if supportet on

server side): connetions to different replicas,data transfer in parallel

Local data processing

Compound documents: Drag-and-drop; in-place editing (notifications)

Components for distribution transparency


21/59

23

Client-Side Support for Transparency

A possible approach to transparent replication of a remoteobject using a client-side solution.

Access: stub

Location: naming and(re-)binding

Replication: proxy

Failure: retry, redirect,cache

Concurrency:transaction monitor


22/59

27

N-Tier

WebServer

GlueLogic

WebBrowser

Java Applet

Servlet

HTML Client

JSP

static contentand templates:

HTMLXHTML

XML

JavaApplication

Distributed Component Based Infrastructure

Legacy System

Database

Server

Wrapper/ConnectorPersistence Manager

Transaction Manager

Session Session Session Session

HTTP Daemon

HTTP

PresentationTier

ResourceTier

BusinessTier

Database Access Protocol:JDBC, SQLJ, or proprietary(e.g. SQL*Net)

Content Mgmt

Business Logic

Distribution Protocol:IIOP, RMI,or proprietary (e.g. DCE)

Libraries

proprietary legacy protocol

proprietary legacyprotocol

Specificservers

Devices WindowsApplication


23/59

29

Architecture

Results from case studies

Often implicitly used by developers


24/59

30

Modeling

Model Controller Views

communicate

communicatecommunicate

DomainModel

TaskModel

PresentationModels

relate

relaterelate

UML ClassDiagram

ConcurTaskTrees

PresentationModeling

MOF

Architecture

Models

ModelingLanguages

Meta-Meta-Model


25/59

31

Server Design Issues

Iterative or concurrent (e.g., multithreaded)

Server interrupt / out-of-band control

Stateless, stateful, soft state, session state

Where to find/bind the server

Name or directory servers

Well known port addresses (0 1023) (see list athttp://www.iana.org/assignments/port-numbers)

Multithreaded server: Simplifies server code

Exploit parallelism for high performance

(multiprocessor workstation)


26/59

32

Client/server binding

a) Client-to-server binding using a daemon as in DCE

b) Client-to-server binding using a superserver as in UNIX (inetd,

forks process)

3.7


27/59

34

Multithreaded Servers

Example: A multithreaded server organized in adispatcher/worker model. (dispatcher also called coordinator;

worker also called servant or object)


28/59

35

Structure of a server

Different architectures are possible

Who creates the thread?

When is the thread created?

Fixed number of threads?

Several design patterns


29/59

36

Pool vs. dynamic thread creation

Thread creation is expensive (100s ofinstructions)

The cost of thread creation can be amortizedover many requests by keeping a threadaround for several requests

A fixed number of threads could be created atstart-up time and assigned to requests as theycome in


30/59

37

Server threading architectures

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

remote

workers

I/O remoteremote I/O

per-connection threads per-object threads

objects objectsobjects


31/59

38

The thread-per-request architecture

A coordinator thread reads incoming requests

As soon as a request is read, it spawns

(creates) a thread to handle the request The new thread

decodes the request;

calls the servant to perform the request

exits


32/59

39

Thread-per-connection architecture

The coordinator thread detects a new client

It connects the incoming client to a new thread

The new thread decodes the request;

calls the servant to perform the request

returns to read next request from same client


33/59

40

The thread-per-servant architecture

Each servant has its own thread and queue

The coordinator reads an incoming request

and inserts it in the queue of appropriateservant

Each servant thread repeatedly takes a

request from its queue and executes it (simpleway of making servants thread-safe througstrict serialization)


34/59

41

Server Clusters

The general organization of a

three-tiered server cluster


35/59




Code Migration

Virtualization

O


36/59

43

Object server

Provides means to access objects remotelyaccording to different activation policies

Object creation on invocation vs. during serverinitialization

Separate memory segments vs. sharing code

(class definition)

Thread policies (single, one per object, one per

request, ...)and pool vs. on demand

object adapter implements policies

Obj Ad (1)


37/59

44

Object Adapter (1)

An object adapter (OA)implements a particularactivation/invocation

policy (OA groupsobjects per policy)

Different OAs may co-

exist in the same server dispatcher

OA is unaware of thespecific object interface

OA extracts referenceand invokes skeletonaccording to policy

E l Th I R ti S t


38/59

45

Example: The Ice Runtime System

Example of creating an object server in Ice.

Th i t f CORBA


39/59

49

The main components of CORBA

clientserver

proxy

or dynamic invocation

implementation

repository objectadapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interface

repository

Request

Replycorecorefor A

Servant

A

R l f CORBA Obj t Ad t


40/59

50

Role of CORBA Object Adapters

Portable and transparent activation of objectimplementations

Creation/management of object references Calling implementation skeleton

Control of multiple server threads

Basic authentication

Deactivation of object implementations

Support for persistent identities

P t bl Obj t Ad t (1)


41/59

52

Portable Object Adaptor (1)

Mapping of CORBA object identifiers to servants.

a) The POA supports multiple servants.

b) The POA supports a single servant.

OID:

POA assigned

or user assigned

Activation

explicit or

on demand

1. Multiple OIDs single servant

2. One servant for all objects

3. Single servant, many objects andtypes (DSI)



42/59

53


My_servant *my_object; // Declare a reference to a C++ objectCORBA::Objectid_var oid; // Declare a CORBA identifier

my_object = new MyServant; // Create a new C++ objectoid = poa ->activate_object (my_object);

// Register C++ object as CORBA OBJECT

Changing a C++ object into a CORBA object.


43/59




Code Migration

Virtualization

Code migration (1)


44/59

55

Code migration (1)

Parameters passed among client and servermay refer not only to data but also to code

perhaps even while being executed! Historical: Balancing of computational load

Distributed Systems: Moving code to where the

data is can lower communication overhead: move query processing to database machine

moving code to client can also improve scalability(e.g. form processing)

Example of Migrating Code


45/59

56

Example of Migrating Code

The principle of dynamically configuring a client tocommunicate to a server. The client first fetches the necessary

software, and then invokes the server (e.g. Java applet).

Code migration (2)


46/59

57

Code migration (2)

Exploit parallelism (linear speed-up of e.g. Websearch)

Flexibility: Moving code can be used tocustomize (i.e. configure) the client dynamicallyand provide service interfaces on demand:Improved versioning and evolution

BUT Security?

BUT Code migration in heterogeneous

systems is costly and intricate! Mobile code offers a different paradigm for

structuring of distributed applications

Models for Code Migration


47/59

58

Models for Code Migration

Alternatives for code migration: Consider code

segment, execution segment, and resource segment

Migration and Local Resources (1)


48/59

59


Resource segment can not always be movedalong without being changed

Three types of process-to-resource bindings Binding by identifier

Binding by value

Binding by type

Three types of resource-to-machine bindings

Unattached resources

Fastened resources

Fixed resources



49/59

60


GRGR

RB (or GR)

GR (or MV)GR (or CP)

RB (or GR, CP)

MV (or GR)CP ( or MV, GR)

RB (or GR, CP)

By identifierBy value

By type

FixedFastenedUnattached

Resource-to machine binding

Process-to-resourcebinding

Actions to be taken with respect to the references to localresources when migrating code to another machine:

GR Establish a global systemwide reference

MV Move the resource

CP Copy the value of the resource

RB Rebind process to locally available resource


50/59




Code Migration

Virtualization

Virtualization (1)


51/59

62

Virtualization (1)

Threads provide illusion of severalprocessors Virtualization extends this idea

to the resources 70s: run legacy software, e.g., IBM 370

90s:

Application software is outliving system (operatingsystem and hardware) portability

Administration of large and heterogeneous systems

and applications flexibility+portability

Isolation: Reliability and security

The Role of Virtualization in DS


52/59

63

The Role of Virtualization in DS

a) General organization between a program,interface, and system.

b) General organization of virtualizing system A on

top of system B.

Interfaces at different levels (2)


53/59

65

Interfaces at different levels (2)

Various interfaces offered by computer systems.

Architectures of Virtual Machines (1)


54/59

66


A process virtual machine, with multipleinstances of (application, runtime)

combinations. E.g., JVM.



55/59

67


A virtual machine monitor, with multiple instancesof (applications, OS) combinations. E.g., VMware,Xen

Migration in Heterogeneous Systems (1)


56/59

68


Can the code segment be executed at all?

Is the execution segment properly

represented? scripting languages and highly portable

languages (Java)

rely on a process virtual machine thatinterprets source code (scripting) orintermediate code (Java)



57/59

69

g g y ( )

recently: migrate the whole computingenvironment (virtual machine monitor):

strong mobility

resources are part of moved environment

service continuation during maintenance

resource bindings: network-to-MAC binding(storage as separate tier)

memory image %



58/59

70

g g y ( )

Ways to handle migration (can be combined)

Pushing memory pages to the new machine and

resending the ones that are later modified duringthe migration process. ( extra effort)

Stopping the current virtual machine; migratememory, and start the new virtual machine.( long service interruption)

Letting the new virtual machine pull in new pagesas needed, that is, let processes start on the new

virtual machine immediately and copy memorypages on demand. ( long migration period)

pre-copy: method 1 + method 2 (~200ms

interruption)

Summary


59/59

76

y

Concurrency is naturally present in adistributed system and needs operating systemsupport

Concurrency may be exploited in several waysin distributed systems: To improve performance by hiding delays due to

blocking

To structure high-performance servers

To structure clients that hide server replication

Other paradigms with different operatingsystem support code migration

virualization

04-operating system support

Documents