UNIX Process Model

1
UNIX Process Model
2
Requirements of anOperating System

• Interleave the execution of multiple processes to
  maximize processor utilization while providing
  reasonable response time
• Allocate resources to processes
• Support interprocess communication and user
  creation of processes

3
Concepts

• Computer platform consists of a collection of
  hardware resources
• Computer applications are developed to perform
  some task
• Inefficient for applications to be written
  directly for a given hardware platform
• Operating system provides a convenient to use,
  feature rich, secure, and consistent interface
  for applications to use
• OS provides a uniform, abstract representation of
  resources that can be requested and accessed by
  application

4
Manage Execution of Applications

• Resources made available to multiple applications
• Processor is switched among multiptle application
• The processor and I/O devices can be used
  efficiently

5
Process

• A program in execution
• An instance of a program running on a computer
• The entity that can be assigned to and executed
  on a processor
• A unit of activity characterized by the execution
  of a sequence of instructions, a current state,
  and an associated set of system instructions

6
Process Elements

• Identifier
• State
• Priority
• Program counter
• Memory pointers
• Context data
• I/O status information
• Accounting information

7
Process Control Block

• Contains the process elements
• Created and manage by the operating system
• Allows support for multiple processes

8
Process Control Block
9
Trace of Process

• Sequence of instruction that execute for a
  process
• Dispatcher switches the processor from one
  process to another

10
Example Execution
11
Trace of Processes
12
(No Transcript)
13
Two-State Process Model

• Process may be in one of two states
• Running
• Not-running

14
Not-Running Process in a Queue
15
Process Creation
16
Process Termination
17
Process Termination
18
Processes

• Not-running
• ready to execute
• Blocked
• waiting for I/O
• Dispatcher cannot just select the process that
  has been in the queue the longest because it may
  be blocked

19
A Five-State Model

• Running
• Ready
• Blocked
• New
• Exit

20
Five-State Process Model
21
Process States
22
Using Two Queues
23
Multiple Blocked Queues
24
Suspended Processes

• Processor is faster than I/O so all processes
  could be waiting for I/O
• Swap these processes to disk to free up more
  memory
• Blocked state becomes suspend state when swapped
  to disk
• Two new states
• Blocked/Suspend
• ReadySuspend

25
One Suspend State
26
Two Suspend States
27
Reasons for Process Suspension
28
Processes and Resources
29
Operating System Control Structures

• Information about the current status of each
  process and resource
• Tables are constructed for each entity the
  operating system manages

30
Memory Tables

• Allocation of main memory to processes
• Allocation of secondary memory to processes
• Protection attributes for access to shared memory
  regions
• Information needed to manage virtual memory

31
I/O Tables

• I/O device is available or assigned
• Status of I/O operation
• Location in main memory being used as the source
  or destination of the I/O transfer

32
File Tables

• Existence of files
• Location on secondary memory
• Current Status
• Attributes
• Sometimes this information is maintained by a
  file management system

33
Process Table

• Where process is located
• Attributes in the process control block
• Program
• Data
• Stack

34
Process Image
35
(No Transcript)
36
Process Control Block

• Process identification
• Identifiers
• Numeric identifiers that may be stored with the
  process control block include
• Identifier of this process
• Identifier of the process that created this
  process (parent process)
• User identifier

37
Process Control Block

• Processor State Information
• User-Visible Registers
• A user-visible register is one that may be
  referenced by means of the machine language that
  the processor executes while in user mode.
  Typically, there are from 8 to 32 of these
  registers, although some RISC implementations
  have over 100.

38
Process Control Block

• Processor State Information
• Control and Status Registers
• These are a variety of processor registers that
  are employed to control the operation of the
  processor. These include
• Program counter Contains the address of the next
  instruction to be fetched
• Condition codes Result of the most recent
  arithmetic or logical operation (e.g., sign,
  zero, carry, equal, overflow)
• Status information Includes interrupt
  enabled/disabled flags, execution mode

39
Process Control Block

• Processor State Information
• Stack Pointers
• Each process has one or more last-in-first-out
  (LIFO) system stacks associated with it. A stack
  is used to store parameters and calling addresses
  for procedure and system calls. The stack pointer
  points to the top of the stack.

40
Process Control Block

• Process Control Information
• Scheduling and State Information
• This is information that is needed by the
  operating system to perform its scheduling
  function. Typical items of information
• Process state defines the readiness of the
  process to be scheduled for execution (e.g.,
  running, ready, waiting, halted).
• Priority One or more fields may be used to
  describe the scheduling priority of the process.
  In some systems, several values are required
  (e.g., default, current, highest-allowable)
• Scheduling-related information This will depend
  on the scheduling algorithm used. Examples are
  the amount of time that the process has been
  waiting and the amount of time that the process
  executed the last time it was running.
• Event Identity of event the process is awaiting
  before it can be resumed

41
Process Control Block

• Process Control Information
• Data Structuring
• A process may be linked to other process in a
  queue, ring, or some other structure. For
  example, all processes in a waiting state for a
  particular priority level may be linked in a
  queue. A process may exhibit a parent-child
  (creator-created) relationship with another
  process. The process control block may contain
  pointers to other processes to support these
  structures.

42
Process Control Block

• Process Control Information
• Interprocess Communication
• Various flags, signals, and messages may be
  associated with communication between two
  independent processes. Some or all of this
  information may be maintained in the process
  control block.
• Process Privileges
• Processes are granted privileges in terms of the
  memory that may be accessed and the types of
  instructions that may be executed. In addition,
  privileges may apply to the use of system
  utilities and services.

43
Process Control Block

• Process Control Information
• Memory Management
• This section may include pointers to segment
  and/or page tables that describe the virtual
  memory assigned to this process.
• Resource Ownership and Utilization
• Resources controlled by the process may be
  indicated, such as opened files. A history of
  utilization of the processor or other resources
  may also be included this information may be
  needed by the scheduler.

44
Processor State Information

• Contents of processor registers
• User-visible registers
• Control and status registers
• Stack pointers
• Program status word (PSW)
• contains status information
• Example the EFLAGS register on Pentium machines

45
Pentium II EFLAGS Register
46
Modes of Execution

• User mode
• Less-privileged mode
• User programs typically execute in this mode
• System mode, control mode, or kernel mode
• More-privileged mode
• Kernel of the operating system

47
Process Creation

• Assign a unique process identifier
• Allocate space for the process
• Initialize process control block
• Set up appropriate linkages
• Ex add new process to linked list used for
  scheduling queue
• Create of expand other data structures
• Ex maintain an accounting file

48
When to Switch a Process

• Clock interrupt
• process has executed for the maximum allowable
  time slice
• I/O interrupt
• Memory fault
• memory address is in virtual memory so it must be
  brought into main memory

49
When to Switch a Process

• Trap
• error or exception occurred
• may cause process to be moved to Exit state
• Supervisor call
• such as file open

50
Change of Process State

• Save context of processor including program
  counter and other registers
• Update the process control block of the process
  that is currently in the Running state
• Move process control block to appropriate queue
  ready blocked ready/suspend
• Select another process for execution

51
Change of Process State

• Update the process control block of the process
  selected
• Update memory-management data structures
• Restore context of the selected process

52
Execution of the Operating System

• Non-process Kernel
• Execute kernel outside of any process
• Operating system code is executed as a separate
  entity that operates in privileged mode
• Execution Within User Processes
• Operating system software within context of a
  user process
• Process executes in privileged mode when
  executing operating system code

53
(No Transcript)
54
(No Transcript)
55
Execution of the Operating System

• Process-Based Operating System
• Implement operating system as a collection of
  system processes
• Useful in multi-processor or multi-computer
  environment

56
UNIX SVR4 Process Management

• Most of the operating system executes within the
  environment of a user process

57
UNIX Process States
58
UNIX Process Image
59
(No Transcript)
60
SpaceID pid Exec(myprogram, 0) Create a new
process running the program myprogram. int
status Join(pid) Called by the parent to wait
for a child to exit, and reap its exit status.
Note child may have exited before parent calls
Join! Exit(status) Exit with status, destroying
process. Note this is not the only way for a
proess to exit!.
Exec parent
Exec child
Join
Exit
61
int pid fork() Create a new process that is a
clone of its parent. exec(program , argvp,
envp) Overlay the calling process virtual
memory with a new program, and transfer control
to it. exit(status) Exit with status,
destroying the process. int pid
wait(status) Wait for exit (or other status
change) of a child.
fork parent
fork child
initialize child context
exec
wait
exit
62
Elements of the Unix Process and I/O Model

• 1. rich model for IPC and I/O everything is a
  file
• file descriptors most/all interactions with the
  outside world are through system calls to
  read/write from file descriptors, with a unified
  set of syscalls for operating on open descriptors
  of different types.
• 2. simple and powerful primitives for creating
  and initializing child processes
• fork easy to use, expensive to implement
• 3. general support for combining small simple
  programs to perform complex tasks
• standard I/O and pipelines good programs dont
  know/care where their input comes from or where
  their output goes

63
Unix File Descriptors

• Unix processes name I/O and IPC objects by
  integers known as file descriptors.
• File descriptors 0, 1, and 2 are reserved by
  convention for standard input, standard output,
  and standard error.
• Conforming Unix programs read input from stdin,
  write output to stdout, and errors to stderr by
  default.
• Other descriptors are assigned by syscalls to
  open/create files, create pipes, or bind to
  devices or network sockets.
• pipe, socket, open, creat
• A common set of syscalls operate on open file
  descriptors independent of their underlying
  types.
• read, write, dup, close

64
Unix File Descriptors Illustrated
user space
kernel
file
pipe
process file descriptor table
socket
system open file table
tty
File descriptors are a special case of kernel
object handles.
The binding of file descriptors to objects is
specific to each process, like the virtual
translations in the virtual address space.
Disclaimer this drawing is oversimplified.
65
The Concept of Fork

• The Unix system call for process creation is
  called fork().
• The fork system call creates a child process that
  is a clone of the parent.
• Child has a (virtual) copy of the parents
  virtual memory.
• Child is running the same program as the parent.
• Child inherits open file descriptors from the
  parent.
• (Parent and child file descriptors point to a
  common entry in the system open file table.)
• Child begins life with the same register values
  as parent.
• The child process may execute a different program
  in its context with a separate exec() system call.

66
Example Process Creation in Unix
The fork syscall returns twice it returns a zero
to the child and the child process ID (pid) to
the parent.
int pid int status 0 if (pid fork()) /
parent / .. pid wait(status) else /
child / .. exit(status)
Parent uses wait to sleep until the child exits
wait returns child pid and status. Wait variants
allow wait on a specific child, or notification
of stops and other signals.
67
include ltunistd.hgt / defines fork(), and pid_t.
/ include ltsys/wait.hgt / defines the wait()
system call. / / storage place for the pid of
the child process, and its exit status. / pid_t
child_pid int child_status / lets fork off a
child process... / child_pid fork() / check
what the fork() call actually did / switch
(child_pid) case -1 / fork() failed /
perror("fork") / print a system-defined
error message / exit(1) case 0 / fork()
succeeded, we're inside the child process /
printf("hello world\n") exit(0)
default / fork() succeeded, we're inside the
parent process / wait(child_status) / wait
till the child process exits / / parent's
process code may continue here... /
68
Child Process Termination

• When a child process exits, it is not immediately
  cleared off the process table. Instead, a signal
  is sent to its parent process, which needs to
  acknowledge it's child's death, and only then the
  child process is completely removed from the
  system.
• The simple way of a process to acknowledge the
  death of a child process is by using the wait()
  system call.

69
Asynchronous Child Death Notification
include ltstdio.hgt / basic I/O routines. /
include ltunistd.hgt / define fork(), etc. /
include ltsys/types.hgt / define pid_t, etc. /
include ltsys/wait.hgt / define wait(), etc. /
include ltsignal.hgt / define signal(), etc. /
/ first, here is the code for the signal
handler / void catch_child(int sig_num) /
when we get here, we know there's a zombie child
waiting / int child_status wait(child_statu
s) printf("child exited.\n")
70
/ define the signal handler for the CHLD signal
/ signal(SIGCHLD, catch_child) / and the
child process forking code... / int
child_pid int i child_pid fork()
switch (child_pid) case -1 / fork()
failed / perror("fork") exit(1) case
0 / inside child process / printf("hello
world\n") sleep(5) / sleep a little, so
we'll have / / time to see what is going on
/ exit(0) default / inside parent process
/ break / parent process goes on,
minding its own business... /
71
Whats So Cool About Fork

• 1. fork is a simple primitive that allows process
  creation without troubling with what program to
  run, args, etc.
• Serves some of the same purposes as threads.
• 2. fork gives the parent program an opportunity
  to initialize the child processespecially the
  open file descriptors.
• Unix syscalls for file descriptors operate on the
  current process.
• Parent program running in child process context
  may open/close I/O and IPC objects, and bind them
  to stdin, stdout, and stderr.
• Also may modify environment variables, arguments,
  etc.
• 3. Using the common fork/exec sequence, the
  parent (e.g., a command interpreter or shell) can
  transparently cause children to read/write from
  files, terminal windows, network connections,
  pipes, etc.

72
Unix as an Extensible System

• Complex software systems should be built
  incrementally from components.
• independently developed
• replaceable, interchangeable, adaptable
• The power of fork/exec/exit/wait makes Unix
  highly flexible/extensible...at the application
  level.
• write small, general programs and string them
  together
• general stream model of communication
• this is one reason Unix has survived
• These system calls are also powerful enough to
  implement powerful command interpreters (shell).

73
The Shell

• The Unix command interpreters run as ordinary
  user processes with no special privilege.
• This was novel at the time Unix was created
  other systems viewed the command interpreter as a
  trusted part of the OS.
• Users may select from a range of interpreter
  programs available, or even write their own (to
  add to the confusion).
• csh, sh, ksh, tcsh, bash choose your flavor...or
  use perl.
• Shells use fork/exec/exit/wait to execute
  commands composed of program filenames, args, and
  I/O redirection symbols.
• Shells are general enough to run files of
  commands (scripts) for more complex tasks, e.g.,
  by redirecting shells stdin.
• Shells behavior is guided by environment
  variables.

74
Limitations of the Unix Process Model

• The pure Unix model has several
  shortcomings/limitations
• Any setup for a new process must be done in its
  context.
• Separated Fork/Exec is slow and/or complex to
  implement.
• A more flexible process abstraction would expand
  the ability of a process to manage another
  externally.
• This is a hallmark of systems that support
  multiple operating system personalities (e.g.,
  NT) and microkernel systems (e.g., Mach).
• Pipes are limited to transferring linear byte
  streams between a pair of processes with a common
  ancestor.
• Richer IPC models are needed for complex software
  systems built as collections of separate
  programs.

75
Process Internals
process descriptor


resources
The address space is represented by page table, a
set of translations to physical memory allocated
from a kernel memory manager. The kernel must
initialize the process memory with the program
image to run.
Each process has a thread bound to the VAS. The
thread has a saved user context as well as a
system context. The kernel can manipulate the
user context to start the thread in user mode
wherever it wants.
Process state includes a file descriptor table,
links to maintain the process tree, and a place
to store the exit status.
76
Mode Changes for Exec/Exit

• Syscall traps and returns are not always
  paired.
• Exec returns (to child) from a trap that never
  happened
• Exit system call trap never returns
• system may switch processes between trap and
  return
• In contrast, interrupts and returns are strictly
  paired.

Exec call
Exec return
Join call
Join return
Exec enters the child by doctoring up a saved
user context to return through.
parent
child
Exec entry to user space
Exit call
77
A Typical Unix File Tree
/
File trees are built by grafting volumes from
different volumes or from network servers.
tmp
usr
etc
bin
vmunix
In Unix, the graft operation is the privileged
mount system call, and each volume is a
filesystem.
ls
sh
project
users
packages
mount point
mount (coveredDir, volume) coveredDir directory
pathname volume device specifier or network
volume volume root contents become visible at
pathname coveredDir
(volume root)
tex
emacs
78
Filesystems

• Each file volume (filesystem) has a type,
  determined by its disk layout or the network
  protocol used to access it.
• ufs (ffs), lfs, nfs, rfs, cdfs, etc.
• Filesystems are administered independently.
• Modern systems also include logical
  pseudo-filesystems in the naming tree, accessible
  through the file syscalls.
• procfs the /proc filesystem allows access to
  process internals.
• mfs the memory file system is a memory-based
  scratch store.
• Processes access filesystems through common
  system calls.

79
Threads

• Overview
• Multithreading Models
• Threading Issues
• Pthreads
• Windows XP Threads
• Linux Threads
• Java Threads

80
Programs and Processes and Threads

• Programs
• A program is a static segment of legal code
  (text)
• A program is an executable sequence of
  instructions
• Processes
• A process is a program in execution
• A process is a basic unit of work
• A process consists of one of more threads of
  execution
• Threads
• A thread is a basic unit of CPU utilization
• Multi-threaded processes share data for greater
  efficiency

81
Thread

• Problem of Process
• The cost of switching between multiple processes
  is relatively high.
• There are often severe limits on the number of
  processes the scheduler can handle efficiently.
• Synchronization variables, shared between
  multiple processes, are typically slow.
• Thread
• Light Weight Processes
• Threads share a common address space, and are
  often scheduled internally in a process

82
Single and Multithreaded Processes
83
Four Primary Benefits of Threading

• Responsiveness
• Interactive applications can respond to user
  while other threads are blocked on I/O or
  performing lengthy computations
• Resource Sharing
• Threads share memory, code, and data, which
  enables several threads of activity within the
  same address space
• Economy/Efficiency
• Resource allocation is costly. Sharing reduces
  overhead and reduces the cost of context
  switching during CPU scheduling
• Solaris Processes 30x more costly to create than
  threads
• Solaris Context switching about 5x slower for
  processes
• Utilization of Multiprocessor Architectures
• Can leverage multi-CPU architectures for genuine
  parallelism

84
User Threads (a.k.a. fibers)

• Thread management done by a user-level threading
  library
• User threads are managed above the kernel without
  kernel support
• Three primary thread libraries
• POSIX Pthreads
• Win32 threads
• Java threads

85
Kernel Threads

• Kernel threads supported and managed directly by
  the OS
• Examples
• Windows XP/2000
• Solaris
• Linux
• Tru64 UNIX
• Mac OS X

86
Multithreading Models

• Threading Model defines the relationship
  between user-level threads and kernel-level
  threads
• Many-to-One
• Many user threads mapped to a single kernel
  thread
• One-to-One
• Each user thread mapped to a unique kernel thread
• Many-to-Many
• Many user threads multiplexed among a potentially
  smaller set of underlying kernel threads

87
Many-to-One Model
Many user-level threads mapped to single kernel
thread
88
Many-to-One

• Many user-level threads mapped to single kernel
  thread
• Examples
• Solaris Green Threads
• GNU Portable Threads (NOT the same as Pthreads)
• Pros (Efficiency)
• Threads managed by threading library (in user
  space)
• Dont need to block for system calls during
  management
• Cons
• Entire process will block if ANY thread makes a
  blocking system call (say, for I/O)
• Cant leverage multi-processing architectures,
  because only one user-level thread can access the
  kernel at a time

89
One-to-one Model
Each user-level thread maps to a unique kernel
thread
90
One-to-One

• Each user-level thread maps to a unique kernel
  thread
• Examples
• Windows NT/XP/2000
• Linux
• Solaris 9 and later
• Pros
• Potential for greater concurrency one thread
  can execute while another is blocked
• Allows multiple threads to run in parallel on
  multi-processors
• Cons
• Creating user thread requires creating a unique
  kernel thread
• Overhead of kernel-thread creation can burden
  performance
• Number of user threads bounded by number of
  kernel threads

91
Many-to-Many Model
Many user level threads are mapped to many kernel
threads
92
Many-to-Many Model

• Many user level threads are mapped to many kernel
  threads
• Allows OS to create a sufficient number of kernel
  threads
• Solaris prior to version 9
• Windows NT/2000 with the ThreadFiber package
• Advantages over Many-to-One and One-to-One
  models
• Developers can create as many user threads as
  necessary
• Corresponding kernel threads can execute in
  parallel
• Other threads can execute while another thread
  blocks

93
Two-Level Model
Like many-to-many, except user threads can also
be bound
94
Two-level Model

• Variation on the many-to-many model, except that
  a user thread can be bound to kernel thread
• Examples
• IRIX
• HP-UX
• Tru64 UNIX
• Solaris 8 and earlier

95
Threading Issues

• Semantics of fork() and exec() system calls
• Thread cancellation
• Signal handling
• Thread pools
• Thread specific data
• Scheduler activations

96
Semantics of fork() and exec()

• Does fork() duplicate only the calling thread or
  all threads?
• Some UNIX systems provide both versions of fork()
  
• Which version should one use?
• If exec() is called immediately after fork()
• Only the calling thread needs to be duplicated
• Why? Because exec() replaces the whole process
  anyway\
• If exec() is not called after fork()
• Then typically duplicate all threads

97
Thread Cancellation

• Cancellations terminating a thread before it
  has finished
• Example Multi-threaded database search
• Example Clicking stop while loading a webpage
• Two general approaches
• Asynchronous cancellation terminates the target
  thread immediately (INTERRUPT)
• Deferred cancellation allows the target thread to
  periodically check if it should be cancelled
  (POLLING)
• Which approach to use?
• Deferred cancellation is safer
• Asynchronous cancellation can be easier/faster

98
Signal Handling

• Signals are used in UNIX systems to notify a
  process that a particular event has occurred
• A signal handler is used to process signals
• Signal is generated by particular event
• Signal is delivered to a process
• Signal is handled
• Options
• Deliver the signal to the thread to which the
  signal applies
• Example Division by zero
• Deliver the signal to every thread in the process
• Example Control-C should kill entire process
• Deliver the signal to certain threads in the
  process
• Assign a specific thread to receive all signals
  to the process

99
Thread Pools

• Thread creation is cheaper than process creation,
  but it still has a cost. Instead, create a pool
  of worker threads.
• Create a number of threads in a pool where they
  await work
• Advantages
• Usually slightly faster to service a request with
  an existing thread than create a new thread
• Allows the number of threads in the
  application(s) to be bound to the size of the pool

100
Thread Specific Data

• Allows each thread to have its own copy of data
• Useful when you do not have control over the
  thread creation process (i.e., when using a
  thread pool)
• Example Transaction processing systems

101
Pthreads

• A POSIX standard (IEEE 1003.1c) API for thread
  creation and synchronization
• API specifies behavior of the thread library,
  implementation is up to development of the
  library
• Common in UNIX operating systems (Solaris, Linux,
  Mac OS X)

102
Linux Threads

• Linux refers to them as tasks rather than threads
• Thread creation is done through clone() system
  call
• clone() allows a child task to share the address
  space of the parent task (process)

103
Java Threads

• Java threads are managed by the JVM
• Java threads may be created by
• Extending Thread class
• Implementing the Runnable interface

104
Data Race
THREAD 1 THREAD 2 a data b data a
b-- data a data b
What if
THREAD 1 THREAD 2 a data b data a
b-- data a data b data data
- 1!!!!!!!
105
Creating a POSIX thread
include ltpthread.hgt int pthread_create
(pthread_t thread_id, const pthread_attr_t
attributes, void (thread_function)(void ),
void arguments) int pthread_exit (void
status)
106
include ltpthread.hgt include ltstdio.hgt
include ltstdlib.hgt define NUM_THREADS 5
void PrintHello(void threadid)
printf("\nd Hello World!\n", threadid)
pthread_exit(NULL) int main(int argc, char
argv) pthread_t threadsNUM_THREADS int
rc, t for(t0tltNUM_THREADSt)
printf("Creating thread d\n", t) rc
pthread_create(threadst, NULL, PrintHello,
(void )t) if (rc) printf("ERROR return code
from pthread_create() is d\n", rc) exit(-1)
pthread_exit(NULL)
107
Thread Argument Passing
struct thread_data int thread_id int sum
char message struct thread_data
thread_data_arrayNUM_THREADS void
PrintHello(void threadarg) struct
thread_data my_data ... my_data (struct
thread_data ) threadarg taskid
my_data-gtthread_id sum my_data-gtsum
hello_msg my_data-gtmessage ...
108
int main (int argc, char argv) ...
thread_data_arrayt. thread_id t
thread_data_arrayt.sum sum
thread_data_arrayt.message messagest
rc pthread_create(threadst, NULL,
PrintHello, (void ) thread_data_arrayt)
...