Chapter 3

Processes
Introduction to Processes
❖To execute a program, an operating system creates a number
of virtual processors, each one for running a different
program.
❖To keep track of these virtual processors, the operating
system has a process table, containing entries to store CPU
register values, memory maps, open files, accounting
information, privileges, etc.
❖Jointly, these entries form a process context.
❖ The processor context contains at least the program
counter, but sometimes also other register values such as
the stack pointer.
 ➢ A process is often defined as a program in execution, that is, a
program that is currently being executed on one of the
operating system’s virtual processors.
◦ Process table
 Entries to CPU register values, memory maps, open files, accounting infor.,
privileges, etc
 Traditional operating systems: concerned with the
“local” management and scheduling of processes.
 Modern distributed systems: a number of other issues
are of equal importance.
 Processes can share a segment of physical memory by
mapping it to their address spaces
◦ data in the segment can be accessed by processes for faster IPC
◦ Processes are usually communicate by sending msgs back and
forth via the OS

3
Inter-process communication (IPC)
➢ Multithreading is also useful in the context of large
applications.
➢ Such Applications are often developed as a
collection of cooperating programs, each to be
executed by a separate process.
➢ Cooperation between programs is implemented
through interprocess communication (IPC)
mechanisms.
➢ This approach is typical for a UNIX environment.
➢ For UNIX systems, these mechanisms typically
include (named) pipes, message queues, and shared
memory segments
➢ The major drawback of all IPC mechanisms is that communication
often requires relatively extensive context switching
Inter-process Communication

Operating system

Figure: Context switching as the result of IPC.

 A thread of control is a seq of instructions being executed
within a process context. Each has its own logical control
flow (pc)
 A multithreaded process have two or more threads within
the same context. They share code, data in heap, and
kernel context(open files, timers, etc)
 Each thread has its own id.

Thread 1 (main thread) Shared code and data Thread 2 (peer thread)
shared libraries
stack 1 stack 2
run-time heap
Thread 1 context: read/write data Thread 2 context:
Data registers read-only code/data Data registers
Condition codes Condition codes
0
SP1 SP2
PC1 Kernel context: PC2
VM structures
Open files
Signal handlers
brk pointer
 A single-thread process
◦ The process as a whole is blocked whenever a blocking system call is
executed. E.g whenever a cell is modified, all dependent cells are automatically updated.
 Multithreading
◦ Becomes possible to exploit parallelism
◦ a blocking call in a thread does not result in the entire process being
blocked.
◦ Useful in the context of large applications
 One application, several cooperating programs, each to be executed by a
separate process.
 Interprocess communication (IPC) is needed if cooperating programs are
implemented.
 Foreground and background work
◦ For example, in a spreadsheet program, one thread could display menus and
read user input, while another thread executes user commands and updates
the spreadsheet.
 Asynchronous processing
◦ For example, as a protection against power failure, one can design a word
processor to write its random access memory (RAM) buffer to disk once
every minute.
 Speed of execution
 Modular program structure

6
 Processes are typically independent, while
threads exist as subsets of a process
 Processes carry considerable state info,
whereas multiple threads within a process
share state as well as memory and other
resources
 Processes have separate address space,
whereas threads share their address space
 Processes interact through system-provided
IPC
 Context switching between threads is an
order of magnitude faster than context
switching between processes
 Ability of an OS to support multiple, concurrent
paths of execution within a single process
Threads in distributed systems
➢An important property of threads is that they
can provide a convenient means of allowing
blocking system calls without blocking the
entire process in which the thread is running.
➢This property makes threads particularly
attractive to use in distributed systems, as it
makes it much easier to express
communication in the form of maintaining
multiple logical connections at the same time.
 Mutli-Threaded Client: to achieve acceptable levels of
perceived performance, it is often necessary to hide
communications latencies.
◦ Consequently, a requirement exists to start communications
while doing something else.
◦ Example: modern web browsers.
◦ This leads to the notion of “truly parallel streams of data”
arriving at a multi-threaded client application.
 Mutli-Threaded servers :Although threading is useful
on clients, it is much more useful in distributed
systems servers.
◦ The main idea is to exploit parallelism to attain high
performance.
◦ A typical design is to organize the server as a single
“dispatcher” with multiple threaded “workers”, as diagrammed
overleaf.

11
 A multithreaded server organized in a dispatcher/worker
model.

12
  What’s a client?
 Definition: “A program which interacts with a human /user and
a remote server.”
 Typically, the user interacts with the client via a GUI.
 Of course, there’s more to clients than simply providing a UI.
Remember the multi-tiered levels of the Client/Server
architecture from earlier …

13
 Definition: “A process that implements a specific
service on behalf of a collection of
clients”.Typically, servers are organized to do
one of two things: Wait and Service
 Iterative: server handles request, then returns
results to the client; any new client requests must
wait for previous request to complete (also useful
to think of this type of server as sequential).
 Concurrent: server does not handle the request
itself; a separate thread or sub-process handles
the request and returns any results to the client;
the server is then free to immediately service the
next client (i.e., there’s no waiting, as service
requests are processed in parallel).

14
 a) Client-to-server binding using a daemon (DCE)
b) Client-to-server binding using a super-server (inetd
on UNIX)

➢ A daemon is a program that

runs in the background and
perform similar task like
windows services.
➢ A super server is usually
programmed to start other
servers as needed

15
 A server tailored to support distributed
objects.
 Does not provide a specific service.

 specific services are implemented by the

objects that reside in the server.
 Provides a facility whereby objects can be
remotely invoked by non-local clients.
 Consequently, object servers are highly
adaptable.
 “A place where objects live”.

 Advantage: extensibility and modularity-

provides to add management interface to the server
16
➢ Process migration or more
specifically, code migration,
can help in achieving
scalability.
➢ Also dynamically configure
clients and servers.
 Under certain circumstances, in addition to
the usual passing of data, passing code (even
while it is executing) can greatly simplify the
design of a distributed system.
 However, code migration can be inefficient
and very costly.
 So, why migrate code?
◦ Biggest single reason: better performance.
◦ The big idea is to move a compute-intensive task
from a heavily loaded machine to a lightly loaded
machine “on demand” and “as required”.

18
 Moving (part of) a client to a server –
processing data close to where the data resides.
It is often too expensive to transport an entire
database to a client for processing, so move the
client to the data.
 Moving (part of) a server to a client – checking
data prior to submitting it to a server. The use
of local error-checking (with JavaScript) on web
forms is a good example of this type of
processing. Error-check the data close to the
user, not at the server.

19
➢ Code migration is often used for load distribution, reducing network
bandwidth, dynamic customization, and mobile agents.
➢ Code migration increases scalability, improves performance, and
provides flexibility.
➢ The principle of dynamically configuring a client to communicate to a
server.
➢ The client first fetches the necessary software, and then invokes the
server.

20
  A running process consists of three
“segments”:
◦ Code Segment – instructions
 The part that contains the set of instructions that
make up the program that is being executed.
◦ Resource Segment – external references.
 The part that contains references to external resources
needed by the process, such as files, printers, devices,
other processes, and so on.
◦ Execution Segment – current state.
 Used to store the current execution state of a process,
consisting of private data, the stack, and the program
counter.

21
 Weak Mobility: just the code is moved – and it
always restarts from its initial state.
◦ e.g. Java Applets.
◦ Comment: simple implementation, but limited
applicability.
 Strong Mobility: the code and the state is moved
– and execution restarts from the next
statement.
◦ e.g. D’Agents.
◦ Comment: very powerful, but hard to implement.
 Sender- vs. Receiver-Initiated.
◦ Which side of the communication starts the migration?
◦ The machine currently executing the code (known as
sender-initiated), or
◦ The machine that will ultimately execute the code
(known as receiver-initiated).
22
 Security Concerns.

 “Blindly trusting that the downloaded code

implements only the advertised interface while
accessing your unprotected hard-disk and
does not send the juiciest parts to heaven-
knows-where may not always be such a good
idea”.

23
 Another issue surrounds where the migrated
code executes:
- Within an existing process (possibly as a
thread)
or
- Within it’s own (new) process space.
- Finally, strong mobility also supports the
notion of “remote cloning”: an exact copy of
the original process, but now running on a
different machine.

24
 Alternatives for code migration.

25