Processes Flashcards

1
Q

What is a process?

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What makes a process different than a thread

A
  • 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.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Process Context

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Basic Process Control Block (PCB)

A

Holds management information / context, one per process

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Program Address Space

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Process Stack

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Process Heap

A
  • 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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Libraries

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Multiple Processes

A
  • 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.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Process Hierarchy

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Resource Allocation

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Creating a Child Process

A
  • In Unix this carried out by **fork()** system call
    • Returns child’s Process ID to parent and 0 to child
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Typical Process States

A
  • Interruptible: operation can be stopped
  • Uninterruptible: operation must complete
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Program Address Space

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Process Stack

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Stack Allocation Test

A