Chapter 4: Processes

1
Chapter 4 Processes

• A primary task of an operating system is to
  manage processes
• Process management
• Issue with multiprogramming
• Not with batch systems
• Some terms and aspects
• Organization in memory
• Text section (program code)
• Data section including stack
• Process State
• Process control block (PCB)

2
State Transitions

• When is a process removed from a running state?
• This happens in cases including
• I/O request Process is placed on I/O queue for a
  device
• Spawn and wait Sometimes when a process creates
  a new process, it must wait until the child
  completes
• Time slice expiration
• Sleep request

3
Process Control Block (PCB)

• Each process has a PCB (p. 97 for figure)
• Maintains context for the process when its not
  running
• Stores other information for process
• Contents vary by process type (e.g., threads,
  tasks)
• When one process leaves a running state, and
  another process enters running state
• (a) save context of current process
• Context of current process saved to PCB for that
  process
• Includes CPU register values instruction
  counter, stack pointer, data registers, status
  register, memory management information
• (b) load the context of the next process
• Context loaded from the PCB for the process
• Includes CPU register values for this process

4
Context Switch

• The last step of a context switch is always to
  load the program counter for the process that is
  about to run
• Why?

5
Process Scheduling

• Schedulers select processes from the queues
• Long-term scheduling
• Which process on disc gets loaded into main
  memory
• Sets degree of multiprogramming
• The number of processes that can be in memory at
  once
• Want mix of jobs
• Some I/O bound (tending to do I/O)
• Some CPU bound (tending to execute CPU
  instructions)
• Short-term scheduling (CPU scheduler)
• Which process in memory gets CPU next
• What differs between algorithms for long-term
  short-term scheduling?

6
Context Switching Issues

• Context switch takes a fixed period of time
• Dependent on hardware (e.g., of machine
  registers)
• Want to minimize this
• This is purely system overhead
• Not executing user processes during the time a
  context switch is occurring
• Threads
• One way of reducing context switch times
• Also known as lightweight processes
• Shorter context switch time than heavyweight
  processes
• Why?

7
Threads

• lightweight process
• Has own program counter, register set, stack
• Shares code, data, open files, etc.
• with other theads within a single heavyweight
  process
• But not with other heavyweight processes
• Has own PCB
• Context will involve program counter, register
  set, stack pointer
• Address space shared with other threads
• Memory management information shared
• Can make context switch faster than between
  heavyweight processes
• Conditions that make it faster?
• System threads user threads

8
Creating Processes

• Often useful for one process (parent) to create a
  new process (child)
• Distinguish between heavyweight and lightweight
  process creation
• Different system (or library) calls
• With multiple processes
• Introduces synchronization issues
• E.g., parent might wait until child dies
• Different methods of starting a child process
• Can start a new program
• Make a copy of all or parts of parents address
  space (e.g., Mach, UNIX)

9
Starting a Process on UNIX

• System call fork
• int fork()
• Creates a new heavyweight process
• New (child) process gets a copy of parent address
  space
• fork() call returns twice!
• Once in address space of child process
• returns 0 in child
• Once in address space of parent process
• returns process ID in parent

10
UNIX process creation

• // parent gets the process ID of the child
• int pid fork()
• if (pid 0)
• // we are in the child
• // do childish things
• else // in parent
• // do parent things

11

• / Example of creating a new process on UNIX /
• include ltstdio.hgt
• int a 1
• void main()
• int pid fork()
• if (pid 0) / in child process /
• printf("Press enter to continue
  in child...\n")
• fflush(stdout)
• getchar()
• a 10
• else / in parent process /
• printf("Value of 'a' before
  waiting for child d\n", a)
• wait(NULL)
• printf("Value of 'a' after
  waiting for child d\n", a)
• fflush(stdout)

OUTPUT Value of 'a' before waiting for child
1 Press enter to continue in child... Value of
'a' after waiting for child 1
12
myprog.c

• include ltstdio.hgt
• int main()
• printf("In myprog...\n")
• fflush(stdout)

13

• / exec.c /
• include ltstdio.hgt
• void main()
• int pid fork()
• if (pid 0) / in child process /
• / end arg list with NULL /
• execl("/home/volf/17/cprince/cs563
  1/examples/myprog", NULL)
• / error if we get past this...
  /
• printf("ERROR Child did not
  start executing...\n")
• else / in parent process /
• printf("waiting for child...\n")
• wait(NULL) / wait for a child
  to die /
• / NULL means we don't get status /
• printf("...child done\n")
• fflush(stdout)

OUTPUT waiting for child... In
myprog... ...child done
14
Process Termination

• Resources must be deallocated
• E.g., PCB
• Memory that is in use, if no other threads
• What happens when parent dies?
• Children can die (cascading termination)
• Children can remain executing
• What happen when child dies
• Parent may be notified

15
Cooperating Processes

• Why do we want to write programs that have
  multiple processes and have those processes
  cooperate?
• Software engineering issues
• Sometimes it is natural to divide a problem into
  multiple processes
• Usually the parts of a program need to cooperate
• Similar to reasons for writing programs with
  multiple functions (e.g., modularity)
• Run-time issues
• Computational speedups (e.g., multiple CPUs)
• Convenience (e.g., printing in background)

16
Cooperating Processes Methods

• Interprocess Communication (IPC)
• Goal Communicating a block of data from one
  process to another
• Operating system supported
• Message passing
• Mailboxes
• Remote Procedure Calls (RPC)
• Synchronization
• Goal having one process wait (block) until
  another has achieved some state
• Methods include
• Semaphores and monitors

17
Message Passing

• Send/receive calls
• Blocking (synchronous)
• Send blocks until receiver executes Receive
• Receive blocks until there is a message
• Fixed-length queue
• Sender blocks if queue is full
• Non-blocking (asynchronous)
• Send buffers message, so Receiver will pick it up
  later
• Needs an unbounded message queue
• Receiver gets a message or an indication of no
  message (e.g., NULL)
• These may be system calls
• Or may be implemented in other ways

Rendezvous
18
Message Passing Direct

• Direct/symmetric
• Both sender and receiver name a process
• Send(P, message) // send to process P
• Receive(Q, message) // receive from process Q
• Direct/asymmetric
• Send(P, message) // send to process P
• Receive(pid, message) // pid gets set to sender

19
MailboxesIndirect Message Passing

• E.g., sockets in UNIX, and ports in Mach
• Mailboxes have names or identifiers
• Also have send/receive system calls
• Processes send messages to mailboxes
• Receiver checks mailbox for messages
• Mailboxes have owners
• E.g., owner may be creating process, or o/s
• Pass privileges to other processes
• e.g., rights to ports in Mach can be sent to
  other processes
• Children may automatically share privileges

20
Remote Procedure Calls (RPC)

• Look like regular function calls to caller
• But, RPC called from a client causes a method
  to be invoked on a remote server
• Remote server process provides implementation
  and processing of method
• Can have blocking or non-blocking semantics
• Normal function call semantics
• blocking or non-blocking?
• Various ways to implement
• E.g., can be implemented using message passing

21
RPC with blocking semantics

• Client process calls an RPC function, which
• Encodes arguments and function name in a message
• Sends message to designated server process
• Waits for reply (causes client to block)
• Server is waiting for messages (e.g., using a
  mailbox)
• Server now
• receives message from client
• extracts arguments and function name out of
  message
• Executes requested function with arguments
• Any return values are encoded in reply message
• sends reply message to client
• waits for next incoming message
• Client
• receives message, decodes continues computing