Processes Silber Chapter 4

1
Processes (Silber Chapter 4)

• Process a program in execution. An entity that
  travels around a program's code, executing the
  instructions it sees.
• Sequential programs
• exactly one process per program,
• Concurrent programs
• several processes exec same program.
• What constitutes a process'' mainly depends
  upon the amount of private state information
  associated with each process
• Processes with very little private memory
  are called threads or light-weight
  processes.
• We examine Java threads in Chapter 5.

2
What does each process need?

• In addition to its program counter, (register
  that tells it where it is in the program), each
  process needs
• A place to store return address.
• Allows processes executing the same subroutine,
  but called from different places, to return to
  their correct calling points.
• Since subroutines can call
  other subroutines, each
  process
  needs its own
  stack of return addresses.

3
Process State A process changes state as it
executes

• New The process is being created.
• Running Instructions are being executed.
• Waiting The process is waiting for some event to
  occur.
• Ready Process waiting to be assigned to a
  processor.
• Terminated The process has finished execution.

4
Process Control Block (PCB).

• Each process' state can be represented in the Op
  Sys by a Process Control Block (PCB).
• A PCB contains (or has links to) all the
  information that a process needs in order to
  properly execute.
• When a process is halted, PCB is given current
  process state info so the process can later be
  restarted exactly where it left off. Includes
• process state - new, ready, etc.
• program counter - addr of next instr
• registers contents of stack pointers, etc
• CPU sked info - priority, ptrs to sked queues
• memory management - base/limit registers
• accounting info - amt of CPU time used, pid
• I/O status - allocated devices, files open.

5
Process Scheduling Queues

• Processes migrate between various queues as
  directed by OS.
• 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.

6
An OS Characterization of Processes

• 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.
• By characterizing processes, an OS using a
  multi-level queuing system can select the "best"
  queue for each process.
• More on mulit-level queues of this nature in
  Chapter 6.

7
Operating System Schedulers

• Long-term scheduler (job scheduler) selects
  which processes should be brought into the ready
  queue.

• Invoked infrequently (order of minutes)
• Controls degree of multiprogramming Seeks
  stability between rate of process creation and
  process completion.
• Time-sharing UNIX systems typically have no LTS
  notion is that users leave when system gets slow.
  
• What happens if long-term scheduler selects all
  CPU bound jobs? All I/O bound jobs?

8
Short-term scheduler

• (aka CPU scheduler) selects process to be
  executed next and allocates CPU.
• Invoked whenever a process
  required to yield CPU (time
  quantum expired, I/O
  req)
• Might be invoked very frequently (on the order of
  milliseconds) due to I/O, so must be fast.

9
Context Switching

• When CPU switches to another process, system
  saves the context of the old process (via PCB)
  and loads the saved state for the new process.
• Time spent conducting context-switch is pure
  overhead
• System does no useful work while switching.
• Time dependent on hardware support (ranges from 1
  to 1000 microseconds).
• Context switching is such a performance
  bottleneck that threads are being used to avoid a
  context switch whenever possible

10
Medium-Term Scheduler

• Some systems (such as time-sharing systems with
  no long-term scheduler) use a Medium-Term
  Scheduler
• Based on the notion that it can be advantages to
  remove some processes from memory, even though
  they are ready and wanting to run)
• Removes these jobs from actively contending for
  CPU
• Serves to reduce the degree of multiprogramming
• To improve process mix, or due to memory
  requirements.

11
Process Creation (UNIX)

• In UNIX, the fork() command starts a new process
  running within the same program, starting at
  statement following the fork() call.
• After the call, both the parent (process that
  called fork()) and the child are both executing
• The child is given its own memory space, which is
  initialized with an exact copy of the parent
  (globals, stack, heap objects, program counter)
• Parent and child then execute independently (as
  per their program counter) when they get the CPU.
  
• fork() returns
• 0 for the child process,
• a negative value if the fork failed, or
• a positive value to the parent, (the process id
  of the child).

12
Example of a UNIX fork() system call

• include ltiostreamgt
• include ltunistd.hgt
• using namespace std
• // g -o fork fork.cpp fork
• char str // global variable
• int f()
• int k
• k fork()
• if (k 0)
• str "child gets "
• return k
• else
• str "parent gets "
• return k
• main()
• int j
• str "the main program "

13
Cooperating Processes

• Independent process cannot effect the execution
  of another process, while cooperating process
  can.
• Producer-Consumer Problem. A classic example of
  cooperating processes
• producer process produces information
• producer's information is consumed by a consumer
  process. ex printer driver buffer.
• unbounded-buffer unlimited buffer size
• Consumer may have to wait for new items to be
  produced,
• Producer can always produce new items.
• bounded-buffer assumes a fixed buffer size.
• Producer must wait if buffer is full,
• Consumer must wait if buffer is empty.

14
more on UNIX fork()
15
ICE Looping fork()s (Dont try this at home)
16
Shared memory solution to Producer-Consumer
Problem

• import java.util.
• public class BoundedBuffer
• public BoundedBuffer()
• // buffer is initially empty
• count 0
• in 0
• out 0
• buffer new ObjectBUFFER_SIZE
• // producer calls this method
• public void enter(Object item)
• // consumer calls this method
• public Object remove()
• public static final int NAP_TIME 5
• private static final int BUFFER_SIZE3
• private volatile int count
• private int in // nxt free buffer posit

• public void enter(Object item)
• while (count BUFFER_SIZE) // no-op
• count // add an item to buffer ICE
• bufferin item
• in (in 1) BUFFER_SIZE
• if (count BUFFER_SIZE)
• System.out.println("Entered "item"Buff
  full")
• else
• System.out.println("Entered " item "
  Buffer Size " count)

public Object remove() Object item
while (count 0) // no-op busy wait
--count // remove an item from buffer item
bufferout out (out 1)
BUFFER_SIZE if (count 0)
println("Consumed "item" Buffer empty")
else println("Consumed "item" Buffer Size "
count) return
item