Transcript Threads - Computer Information Systems

ICS362 Distributed Systems
Dr. Ken Cosh
Week 3
Review

Architectural Styles
–
–
–
–

Layered Architectures
Object-Based
Data-Centred
Event-Based
System Architectures
–
Centralised / Decentralised / Hybrid
This Week

Processes
–
–
–
–
–
Threads
Virtualisation
Clients
Servers
Code Migration
What is a Process?

OS
–

A program in execution
Key Issue
–
–
Managing and Scheduling Processes
Both in terms of OS and in terms of Distributed
Systems
Processes

The OS creates virtual processors
–

OS has a process table
–
–

Each for running different programs
To keep track of the virtual processors
CPU register values, memory maps, open files, privileges,
etc.
OS manage these independent processes
–
–
One process can not affect another
i.e. concurrency transparency
Achieving Concurrency Transparency

Computationally Expensive
–
Allocation


Create complete independent address space
Initialising memory segments
–
–
Potentially moving existing data
Switching



Saving CPU context
Modify Memory Management Unit (MMU)
Potentially swapping processes between main memory and
hard disk
–
If more processes than main memory
Threads

Threads are like processes
–
–
Executing code independently from other threads
But with no attempt at concurrency transparency

–
–
Threads can share the same address space
Computationally less expensive
But programming requires more intellectual effort
Multithreading

Consider a spreadsheet program
–
–
Editing one cell can cause updates to formulae
throughout multiple sheets.
How do we allow user input concurrently with
calculations?

And perhaps autosaving
Thread Implementation

Normally in the form of a thread package
–

Containing operations to create and destroy
threads & synchronisation variables such as
mutexes.
Implementation can be done in different ways
–
–
–
Executed entirely in user mode
Kernel responsible for scheduling
Hybrid
User Level thread library

All thread administration is kept in user’s address
space;
–
Cheap to create & destroy threads

Switching between threads is also cheap

However, a blocking system call will block the
process – and hence any other threads in the
process.
–
E.g. when waiting for input
Kernel level threads


That problem is avoided by implementing
threads in the OS kernel.
Then, every thread operation is carried out
by the kernel, through system calls
–

Creation, deletion, synchronisation etc.
Switching threads becomes as expensive as
switching processes
Hybrid Implementation

Light Weight Processes (LWP)
–
–
LWPs run in user space in the context of a single
process, but several LWPs can run per process
with a shared address space.
Creation, deletion operations etc. run in user
space without intervention by the kernel.
Threads in DS


A convenient way of allowing blocking
system calls without blocking an entire
process.
In DS, threads can be separated to different
processors (clients or servers)
Multithreaded Clients

Example: A Web Browser
–
–
–
–
Setting up connection
Read incoming data
Pass to display component
Potentially connecting to multiple load balanced
replicated servers to transfer data in parallel
streams
Multithreaded Servers

Suppose a request comes into a single threaded
server.
–

With multithreads, a dispatcher thread can assign a
worker thread to read data from a file system
–

The request needs to be completed before any more
requests can come
Normally a blocking operation
Meanwhile the dispatcher thread can deal with more
reads, or responses from other worker threads.
Multithreaded Servers
Worker
Thread
Dispatcher
Thread
Operating System
Request from network
Virtualisation

Of course, we are still referring to a single processor,
but giving the illusion of simultaneous execution.
–

‘Resource Virtualisation’
Renewed interest in virtualisation as distributed
systems become popular
–
–
Extending (or replacing) an existing interface to mimic the
behaviour of another system
E.g. to allow software to run on a different platform.
Applications of virtualisation

Hardware & Low level systems software
evolves quicker than application software.
–

Virtualisation allows older, more stable, software
to run on newer platforms
Networking is pervasive across
heterogeneous computers
–
Virtualisation helps by letting each application run
on its own virtual machine.
Virtual Machine Implementation

Virtualisation mimics the behaviour of various
interfaces:
–
–
–
–
Interface between Hardware and Software, which can be
invoked by any program.
Interface between Hardware and Software, which can be
invoked by privileged programs such as the OS.
Interface of system calls offered by an OS
Interface of library calls offered by an API (essentially hiding
the OS system calls).
Computer Systems Interfaces
Application
Library Functions
Library
General
Instructions
System Calls
Operating System
Privileged
Instructions
Hardware
Process Virtual Machine
Application
Runtime System
Operating System
Hardware
Virtualisation is for single processes
Virtual Machine Monitor
Application
Operating System
Virtual Machine Monitor
Hardware
Multiple different Operating Systems running concurrently on the same platform
Clients

Provide means for users to interact with
remote servers
–
1) Fat Client


–
Application specific protocol
E.g. Agenda application running on a PDA,
synchronising with a remote (possibly shared) agenda.
2) Thin Client



Application neutral protocol
Client is a terminal with no need for local storage
Example – X Window
X Window


Oldest, still widely used networked user
interface.
The heart is the ‘X-kernel’ OS running on the
client
–
–
Containing terminal specific device drivers for
monitor, keyboard & mouse.
Captures keyboard / mouse events and made
available through Xlib library, running elsewhere
and communicating through X protocol.
X Window System
Window
Manager
Xlib
Local OS
Application
Xlib
Local OS
X Kernel
Device Drivers
X Window Manager

Application which dictates the “look and feel”
of the display
–
–

How to display windows, what buttons etc.
Other applications adhere to these rules.
So.. Confusingly the X Kernel acts as a
server where applications play the role of
clients!
Communication Efficiency

This takes a lot of data communication!
–
–
–
–

Video stream 30 frames per second
320x240 screen (PDA)
24bits per pixel
= 53 Mbps!
Compression techniques are necessary
Increasing UI Complexity


Drag & Drop Functionality
Consider a document which contains text &
images
–
–

Document contains multiple applications
Suppose we want to rotate an image
It needn’t reside on the client, but the client
may require more processing power.
–
Or the Client needs to be fatter
Servers

A process implementing a specific service on
behalf of a collection of clients
–
–
–
It waits for an incoming request
Then ensures the request is taken care of
Returns to wait for the next request
Iterative vs Concurrent

Iterative Server
–

Handles the request itself and returns response if
necessary to the user.
Concurrent Server
–
–
Passes the request to a separate thread or
another process.
The other process is responsible for responding
to the requesting client.
Ports


Clients send requests to an endpoint (port)
Servers listen to a particular port
–

E.g. FTP on TCP port 21, HTTP on TCP port 80
Or a Daemon can listen to a port and contact
the specific server when requests arrive.
Stateless Servers



Does not keep information on the state of its clients.
Can change its state without informing clients
Once an HTTP server delivers the files it forgets
about the client.
–
Technically the web server might log all client requests as
useful information, but if the information is lost there is no
damage to the service.
Soft State Servers

Server which promises to maintain state on
behalf of the client – for a limited time
–
E.g. server promises to inform client about
updates, but only for a limited time.
Stateful Server

Server maintains persistent information on its
clients.
–

E.g. server allows a client to keep a local copy of
a file (possibly for updating). Server then
maintains a list of client/file entries.
This can improve performance, however if
the server crashes it has to restore the list.
Session State vs Permanent State


Bear in mind that Permanent State is
generally stored in a database, such as
customer information, purchases etc.
Maintaining Session State is part of Stateful
Server design.
Stateful vs Stateless

Should not affect services provided by the
server.
–
If files have to be opened before they can be read
from or written to, then either design should mimic
this behaviour.
Server Clusters


A collection of machines connected through
a network, where each machine runs one or
more servers.
Logically organised into three tiers (layers)
–
–
–
Switch – through which requests are routed
Application – servers where programs run
File/Database – where the data is stored
Server Clusters
Database / File Servers
Logical
Switch
Application Servers
Client
Requests
First Tier
Second Tier
Third Tier
Server Clusters

Some systems combine the data and
application into a single server resulting in a
two tiered system architecture
–
E.g. Streaming Media
Server Clusters

Often Offer Multiple Services, with different
machines running different services
–
–

Switch needs to be able to distinguish requests and
services.
Often caused by limitations on available software &
hardware, and different administrators not wanting to
interfere with each other.
Leads to some overloaded servers, while others are
idle.
–
Possibility for code migration?
Code Migration


So far we have been concerned with passing data.
Sometimes it is useful to pass programs
–

Even while they are running
Sometimes overall system performance can be
improved by moving processes from overloaded
machines to lightly loaded machines.
–
Load in terms of CPU queue length or CPU utilisation
Examples

1) A client application needs to perform many
database operations
–

Why not move the operations closer to the data
and then only return the results?
2) A form needs to be filled in, processed and
then translated into a series of database
operations
–
Why not do the form processing on the client?
Code Migration

Benefits
–
–
–

Flexibility
Dynamically configured distributed systems
Software need not be pre-installed
Concerns
–
Security
Strong vs Weak Mobility

A process consists of 3 segments
–
–
–
Code Segment – set of instructions
Resource Segment – references to necessary
external resources (files, devices, printers etc.)
Execution Segment – current execution state of
the process
Weak Mobility

The code segment is sent
–
–
–
In this case the code must always begin from a
predefined point (perhaps the start)
E.g. Java Applets
Only requires that the target machine is capable
of running the code
Strong Mobility

The execution segment is transferred as well
as the code segment.
–
–
Code can be stopped, moved to a new machine,
and restarted from where it was.
More general than weak mobility, but harder to
implement.
The Resource Segment

Consider; you’ve designed your website on
localhost, and then upload it to a webserver
–
–
Absolute vs Relative URLs?
Changing IP addresses
The Resource Segment

Binding by Identifier
–

Binding by Value
–
–

A precisely referenced resource, and nothing else!
It doesn’t matter which resource is used, so long as the
correct value is returned.
Does it matter if I use my C++ libraries or yours?
Binding by Type
–
What type of device are we referring to – a printer? A
monitor?
Kinds of Resource

Unattached Resources
–

Fastened Resources
–

Easily moved – e.g. data files associated with the program
Possible, but relatively high cost – e.g. moving a database –
not dependent on current machine, but infeasible to move to
a new environment
Fixed Resources
–
Cannot be moved from environment or machine – e.g. local
resources, or a local comunication end point.
Solutions?


With 3 kinds of process-to-resource bindings
and 3 kinds of resource-to-machine bindings,
there are 9 combinations to consider.
And 4 common solutions
–
–
–
–
Establish a Global System wide reference (GR)
Move the Resource (MV)
Copy the Value of the Resource (CP)
Rebind process to a locally available resource
(RB)
Solutions
Unattached
Fastened
Fixed
By Identifier
MV (or GR)
GR (or MV)
GR
By Value
CP (or MV,GR)
GR (or CP)
GR
By Type
RB (or MV, CP)
RB (or GR, CP)
RB (or GR)