 Process Concept

 Process Scheduling
 Operations on Processes
 Interprocess Communication
 Examples of IPC Systems
 Communication in Client-Server Systems

 Memperkenalkan konsep proses – sebagai sebuah  Sebuah OS menjalankan berbagai macam program dengan
program yang sedang dijalankan, yang merupakan cara:
dasar komputasi  Batch system – jobs

 Menggambarkan fitur proses, termasuk penjadwalan,  Time-shared systems – user programs or tasks
pembuatan dan penghentian proses dan komunikasi  Istilah pada Textbook job, process, task dapat diartikan sama
proses
 Process – program yang dieksekusi; eksekusi proses process
 Menjelaskan interprocess communication execution must progress in sequential fashion
menggunakan shared memory dan message passing
 Multiple parts
 Menggambarkan komunikasi di client-server systems  The program code, also called text section
 Current activity including program counter, processor registers
 Stack containing temporary data
 Function parameters, return addresses, local variables
 Data section containing global variables
 Heap containing memory dynamically allocated during run time

3 4

1
  Program is passive entity stored on disk (executable
file), process is active
 Program becomes process when executable file loaded into
memory
 Execution of program started via GUI mouse clicks,
command line entry of its name, etc
 One program can be several processes
 Consider multiple users executing the same program

5 6

 As a process executes, it changes state

 new: The process is being created
 running: Instructions are being executed
 waiting: The process is waiting for some event to occur
 ready: The process is waiting to be assigned to a processor
 terminated: The process has finished execution

7 8

2
Information associated with each
process
(also called task control block)
 Process state – running, waiting, etc
 Program counter – location of
instruction to next execute
 CPU registers – contents of all
process-centric registers
 CPU scheduling information-
priorities, scheduling queue pointers
 Memory-management information –
memory allocated to the process
 Accounting information – CPU used,
clock time elapsed since start, time
limits
 I/O status information – I/O devices
allocated to process, list of open files

9 10

 So far, process has a single thread of execution Represented by the C structure task_struct
 Consider having multiple program counters per process
 Multiple locations can execute at once pid t_pid; /* process identifier */
 Multiple threads of control -> threads long state; /* state of the process */
unsigned int time_slice /* scheduling information */
 Must then have storage for thread details, multiple struct task_struct *parent; /* this process’s parent */
struct list_head children; /* this process’s children */
program counters in PCB struct files_struct *files; /* list of open files */
 See next chapter struct mm_struct *mm; /* address space of this process */

11 12

3
  Queueing diagram represents queues, resources, flows
 Maximize CPU use, quickly switch processes onto CPU
for time sharing
 Process scheduler selects among available processes
for next execution on CPU
 Maintains scheduling queues of processes
 Job queue – set of all processes in the system
 Ready queue – set of all processes residing in main
memory, ready and waiting to execute
 Device queues – set of processes waiting for an I/O device
 Processes migrate among the various queues

13 14

 Short-term scheduler (or CPU scheduler) – selects which process should  Medium-term scheduler can be added if degree of multiple
be executed next and allocates CPU
programming needs to decrease
 Sometimes the only scheduler in a system
 Short-term scheduler is invoked frequently (milliseconds)  (must be  Remove process from memory, store on disk, bring back in
fast) from disk to continue execution: swapping
 Long-term scheduler (or job scheduler) – selects which processes should
be brought into the ready queue
 Long-term scheduler is invoked infrequently (seconds, minutes)  (may
be slow)
 The long-term scheduler controls the degree of multiprogramming

 Processes can be described as either:

 I/O-bound process – spends more time doing I/O than computations,
many short CPU bursts
 CPU-bound process – spends more time doing computations; few very
long CPU bursts
 Long-term scheduler strives for good process mix

15 16

4
 Some mobile systems (e.g., early version of iOS) allow only  When CPU switches to another process, the system must
one process to run, others suspended save the state of the old process and load the saved
state for the new process via a context switch
 Due to screen real estate, user interface limits iOS provides
for a  Context of a process represented in the PCB
 Single foreground process- controlled via user interface
 Context-switch time is overhead; the system does no
 Multiple background processes– in memory, running, but not useful work while switching
on the display, and with limits
 The more complex the OS and the PCB  the longer the
 Limits include single, short task, receiving notification of events, context switch
specific long-running tasks like audio playback
 Time dependent on hardware support
 Android runs foreground and background, with fewer limits  Some hardware provides multiple sets of registers per CPU
 Background process uses a service to perform tasks  multiple contexts loaded at once
 Service can keep running even if background process is
suspended
 Service has no user interface, small memory use

17 18

 System must provide mechanisms for:  Parent process create children processes, which, in
 process creation, turn create other processes, forming a tree of processes
 process termination,  Generally, process identified and managed via a
 and so on as detailed next process identifier (pid)
 Resource sharing options
 Parent and children share all resources
 Children share subset of parent’s resources
 Parent and child share no resources

 Execution options
 Parent and children execute concurrently
 Parent waits until children terminate

19 20

5
  Address space
init
pid = 1
 Child duplicate of parent
 Child has a program loaded into it

 UNIX examples
login
pid = 8415
kthreadd
pid = 2
sshd
pid = 3028  fork() system call creates new process
 exec() system call used after a fork() to replace the
process’ memory space with a new program
bash khelper pdflush sshd
pid = 8416 pid = 6 pid = 200 pid = 3610

emacs tcsch
ps
pid = 9204 pid = 4005
pid = 9298

21 22

23 24

6
 Process executes last statement and then asks the  Some operating systems do not allow child to exists if its parent
operating system to delete it using the exit() system has terminated. If a process terminates, then all its children
call. must also be terminated.
 Returns status data from child to parent (via wait())  cascading termination. All children, grandchildren, etc. are
terminated.
 Process’ resources are deallocated by operating system  The termination is initiated by the operating system.
 Parent may terminate the execution of children processes  The parent process may wait for termination of a child process
using the abort() system call. Some reasons for doing by using the wait()system call. The call returns status
so: information and the pid of the terminated process
 Child has exceeded allocated resources pid = wait(&status);
 Task assigned to child is no longer required  If no parent waiting (did not invoke wait()) process is a
 The parent is exiting and the operating systems does not zombie
allow a child to continue if its parent terminates
 If parent terminated without invoking wait , process is an
orphan

25 26

 Processes within a system may be independent or

 Many web browsers ran as single process (some still do)
cooperating
 If one web site causes trouble, entire browser can hang or crash
 Cooperating process can affect or be affected by other
 Google Chrome Browser is multiprocess with 3 different processes, including sharing data
types of processes:
 Reasons for cooperating processes:
 Browser process manages user interface, disk and network I/O
 Information sharing
 Renderer process renders web pages, deals with HTML,  Computation speedup
Javascript. A new renderer created for each website opened
 Modularity
 Runs in sandbox restricting disk and network I/O, minimizing effect of
security exploits  Convenience

 Plug-in process for each type of plug-in  Cooperating processes need interprocess communication
(IPC)
 Two models of IPC
 Shared memory
 Message passing

27 28

7
 (a) Message passing. (b) shared memory.  Independent process cannot affect or be affected by the
execution of another process
 Cooperating process can affect or be affected by the
execution of another process
 Advantages of process cooperation
 Information sharing
 Computation speed-up
 Modularity
 Convenience

29 30

 Paradigm for cooperating processes, producer  Shared data

process produces information that is consumed by a #define BUFFER_SIZE 10
consumer process typedef struct {
 unbounded-buffer places no practical limit on the size of . . .
the buffer } item;
 bounded-buffer assumes that there is a fixed buffer size
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;

 Solution is correct, but can only use BUFFER_SIZE-1 elements

31 32

8
 item next_consumed;
item next_produced;
while (true) { while (true) {
while (in == out)
/* produce an item in next produced */
; /* do nothing */
while (((in + 1) % BUFFER_SIZE) == out) next_consumed = buffer[out];
; /* do nothing */ out = (out + 1) % BUFFER_SIZE;
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE; /* consume the item in next consumed */

} }

33 34

 An area of memory shared among the processes that  Mechanism for processes to communicate and to
wish to communicate synchronize their actions
 The communication is under the control of the users
processes not the operating system.  Message system – processes communicate with each
other without resorting to shared variables
 Major issues is to provide mechanism that will allow
the user processes to synchronize their actions when
they access shared memory.  IPC facility provides two operations:
 send(message)
 Synchronization is discussed in great details in
 receive(message)
Chapter 5.
 The message size is either fixed or variable

35 36

9
 If processes P and Q wish to communicate, they need to:  Implementation of communication link
 Establish a communication link between them  Physical:
 Exchange messages via send/receive  Shared memory
 Hardware bus
 Implementation issues:  Network
 How are links established?  Logical:
 Can a link be associated with more than two processes?  Direct or indirect
 How many links can there be between every pair of  Synchronous or asynchronous
communicating processes?  Automatic or explicit buffering
 What is the capacity of a link?
 Is the size of a message that the link can accommodate fixed or
variable?
 Is a link unidirectional or bi-directional?

37 38

 Processes must name each other explicitly:  Messages are directed and received from mailboxes (also
 send (P, message) – send a message to process P referred to as ports)
 receive(Q, message) – receive a message from process Q  Each mailbox has a unique id
 Processes can communicate only if they share a mailbox
 Properties of communication link
 Links are established automatically  Properties of communication link
 A link is associated with exactly one pair of communicating  Link established only if processes share a common mailbox
processes  A link may be associated with many processes
 Between each pair there exists exactly one link  Each pair of processes may share several communication links
 The link may be unidirectional, but is usually bi-directional  Link may be unidirectional or bi-directional

39 40

10
 Operations  Mailbox sharing
 create a new mailbox (port)  P1, P2, and P3 share mailbox A
 send and receive messages through mailbox  P1, sends; P2 and P3 receive
 destroy a mailbox  Who gets the message?

 Primitives are defined as:  Solutions

 Allow a link to be associated with at most two processes
send(A, message) – send a message to mailbox A
 Allow only one process at a time to execute a receive
receive(A, message) – receive a message from mailbox A operation
 Allow the system to select arbitrarily the receiver.
Sender is notified who the receiver was.

41 42

 Message passing may be either blocking or non-

blocking  Queue of messages attached to the link.
 Blocking is considered synchronous  implemented in one of three ways
 Blocking send -- the sender is blocked until the message is 1. Zero capacity – no messages are queued on a link.
received Sender must wait for receiver (rendezvous)
 Blocking receive -- the receiver is blocked until a 2. Bounded capacity – finite length of n messages
message is available Sender must wait if link full
 Non-blocking is considered asynchronous 3. Unbounded capacity – infinite length
 Non-blocking send -- the sender sends the message and Sender never waits
continue
 Non-blocking receive -- the receiver receives:
 A valid message, or
 Null message
 Different combinations possible
 If both send and receive are blocking, we have a
rendezvous

43 44

11
  A socket is defined as an endpoint for communication
 Sockets
 Remote Procedure Calls  Concatenation of IP address and port – a number included
at start of message packet to differentiate network services
 Pipes on a host
 Remote Method Invocation (Java)
 The socket 161.25.19.8:1625 refers to port 1625 on host
161.25.19.8

 Communication consists between a pair of sockets

 All ports below 1024 are well known, used for standard
services

 Special IP address 127.0.0.1 (loopback) to refer to system

on which process is running

45 46

 Three types of sockets

 Connection-oriented
(TCP)
 Connectionless (UDP)
 MulticastSocket class–
data can be sent to
multiple recipients

 Consider this “Date”

server:

47 48

12
 Remote procedure call (RPC) abstracts procedure calls  Data representation handled via External Data
between processes on networked systems Representation (XDL) format to account for different
 Again uses ports for service differentiation architectures
 Big-endian and little-endian
 Stubs – client-side proxy for the actual procedure on
the server  Remote communication has more failure scenarios than
local
 The client-side stub locates the server and marshalls
 Messages can be delivered exactly once rather than at
the parameters
most once
 The server-side stub receives this message, unpacks
 OS typically provides a rendezvous (or matchmaker)
the marshalled parameters, and performs the
procedure on the server service to connect client and server

 On Windows, stub code compile from specification

written in Microsoft Interface Definition Language
(MIDL)

49 50

 Acts as a conduit allowing two processes to

communicate
 Issues:
 Is communication unidirectional or bidirectional?
 In the case of two-way communication, is it half or full-
duplex?
 Must there exist a relationship (i.e., parent-child) between
the communicating processes?
 Can the pipes be used over a network?

 Ordinary pipes – cannot be accessed from outside the

process that created it. Typically, a parent process
creates a pipe and uses it to communicate with a child
process that it created.
 Named pipes – can be accessed without a parent-child
relationship.

51 52

13
 Ordinary Pipes allow communication in standard producer-
consumer style  Named Pipes are more powerful than ordinary pipes
 Producer writes to one end (the write-end of the pipe)  Communication is bidirectional
 Consumer reads from the other end (the read-end of the pipe)  No parent-child relationship is necessary between the
 Ordinary pipes are therefore unidirectional communicating processes
 Require parent-child relationship between communicating  Several processes can use the named pipe for
processes
communication
 Provided on both UNIX and Windows systems

 Windows calls these anonymous pipes

 See Unix and Windows code samples in textbook

53 54

14