Processes

Question 1

What is a process?

Answer 1

• Running instance of a program
  
  • Program loader, invoked by exec(), retrieves and unpacks executable
    
    • On disk formats, such as Executable and Linkable Format (ELF) files, include metadata giving expected memory layout
• Note a thread is a flow of execution within process
  
  • As most context/state information per process
  • Threads are much more lightweight
    
    • Per thread state little more than CPU registers
    • Kernel may, or may not, natively support threads
      
      • Relatively easy to implement user space threads

Question 2

What makes a process different than a thread

Answer 2

• When running a program, process carry access, permission, etc. that program has over a file system, different bits of hardware, so on and so forth.
• While thread do not carry that extra baggage, thus more efficient and lightweight.

Question 3

Process Context

Answer 3

• Processes defined by their **context**, including
  
  • Contents of CPU registers
  • Memory map/layout (segments, pages, …)
  • Open files and current position in each
  • On-going communication state
    
    • Message queues
    • Signals e.g. KILL, semaphores, …
  • Configured timers or alarms
  • Accounting info. / Resource usage
    
    • Return state of any children

Question 4

Basic Process Control Block (PCB)

Answer 4

Holds management information / context, one per process

Question 5

Program Address Space

Answer 5

Question 6

Process Stack

Answer 6

• Common way of implementing function calls
  
  • Function parameters + return address placed on stack before call
  • There is no standard, could use mix of registers and stack, …
• Grows and shrinks in blocks (frames) with function calls
  
  • On x86 stack grows down, from high to low memory address

Question 7

Process Heap

Answer 7

• Predefined memory areas are often too restrictive
  
  • For example, arrays can’t expand if more data than expected
• So, typically allocate memory dynamically as needed
  
  • Elements in linked-list, queue, graph, …
  • New object instances, etc.
• Use library calls to expand and (possibly) contract heap
  
  • memory = malloc()
  • free(memory)

Question 8

Libraries

Answer 8

Question 9

Multiple Processes

Answer 9

• Each process has running state (context)
  
  • These may be from different programs or they may be instances of the same program
  • Instruction and Stack pointers, status flags, …
• When we swap from one to the other, we store the context of the process that is being suspended, put that within the process, control block.
• We then determine which process should run next, we go to it’s process control block, recover the context or the information that tells us what state that process was in when it last ran.
• We load that into the registers and the data structures of the operating system.
• And we can continue with that process
• Process should not have access to things in the operating system
• It shouldn’t be able to see data structures that correspond to a different process, this problem might occur when we place the code of the operating system and the data structures of the operating system in the top memory space of process.

Question 10

Process Hierarchy

Answer 10

• Processes can spawn child processes
  
  • Limit on number imposed by system
    
    • Per process (for fairness)
    • System wide (for system stability)
• Each child has parent process
  
  • Ultimately responsible for resources used by child
• In Unix, /sbin /init (process1) is ultimate parent of all processes

Question 11

Resource Allocation

Answer 11

• Should take account of process hierarchy
• Parents responsible for children
  
  • Children take share of parent’s time and resource allocation
  • Shouldn’t be able to spawn lots of child processes to obtain more resources

Question 12

Creating a Child Process

Answer 12

• In Unix this carried out by **fork()** system call
  
  • Returns child’s Process ID to parent and 0 to child

Question 13

Typical Process States

Answer 13

• Interruptible: operation can be stopped
• Uninterruptible: operation must complete

Question 14

Program Address Space

Answer 14

Question 15

Process Stack

Answer 15

• Common way of implementing function calls
  
  • Function parameters + return address placed on stack before call
  • There is no standard, could use mix of registers and stack, …
• Grows and shrinks in blocks (frames) with function calls
  
  • On x68 stacks grows down

Question 16

Stack Allocation Test