Operating Systems 2019F Lecture 5: Difference between revisions
Created page with "==Topics== * signals * background processes * terminal state * assembly code * memory management" |
No edit summary |
||
Line 1: | Line 1: | ||
== | ==Video== | ||
Video from the lecture given on September 18, 2019 [https://homeostasis.scs.carleton.ca/~soma/os-2019f/lectures/comp3000-2019f-lec05-20190918.m4v is now available]. | |||
==Notes== | |||
<pre> | |||
Lecture 5 | |||
--------- | |||
Assignment 1 | |||
* signals | * signals | ||
* background processes | * background processes | ||
* terminal state | * terminal state | ||
Other stuff | |||
* assembly code | * assembly code | ||
* memory management | * memory management | ||
Signals | |||
------- | |||
* messages that processes can receive at any time | |||
* sent by the kernel, sometimes on behalf of other processes | |||
* (kind of like hardware interrupts) | |||
race conditions in single-threaded processes | |||
Memory management | |||
----------------- | |||
memory can be allocated | |||
* at compile time (statically) | |||
* dynamically, on the stack | |||
* dynamically, on the heap | |||
stack | |||
----- | |||
stack pointer = 2000 | |||
2000 2512 | |||
2004 1123 | |||
2008 4 | |||
a = 2512 | |||
b = 1123 | |||
c = 4 | |||
pop a | |||
stack pointer = 2004 | |||
2004 1123 | |||
2008 4 | |||
push d = 9999 | |||
stack pointer = 2000 | |||
2000 9999 | |||
2004 1123 | |||
2008 4 | |||
Typical memory map | |||
ffffffff | |||
command line arguments | |||
stack (grows down) | |||
heap (grows up) | |||
code | |||
00000000 | |||
C by default doesn't have a heap | |||
- that is managed by functions in the standard library, e.g. malloc() | |||
Why is the heap such a pain to manage? | |||
- allocations aren't ordered in time | |||
- allocations aren't ordered in size | |||
Heap: | |||
Time allocated data | |||
Inital map: | |||
0 ......11111111........2222222222222222....33333333333333. | |||
Allocate #4, size 8 | |||
1 ......11111111444444442222222222222222....33333333333333. | |||
Allocate #5, size 8 -> fail | |||
2 ......11111111444444442222222222222222....33333333333333. | |||
Free #4 | |||
3 ......11111111........2222222222222222....33333333333333. | |||
Allocate #6, size 2 | |||
4 ......11111111...66...2222222222222222....33333333333333. | |||
This problem of lack of contiguous memory is known as fragmentation | |||
You can never escape fragmentation, but you can reduce its impact | |||
One solution: handles | |||
- pointers to pointers | |||
- advantage: memory manager can move memory | |||
- disadvantage: handles have to be dereferenced and locked before use | |||
We almost never use handles nowadays | |||
Another solution: fixed-sized allocation | |||
- always allocate storage in fixed-sized blocks | |||
- just need a way to assemble contiguous memory out of fixed-sized blocks | |||
Filesystems on disks are normally fixed-sized allocations (blocks) | |||
- have to assemble blocks together to get contigous, variable-sized storage | |||
units (e.g. files) | |||
filesystem defragmentation tries to move blocks around so files are allocated | |||
contiguous ranges of blocks | |||
internal versus external fragmentation | |||
internal: lost space inside blocks | |||
external: lost space between blocks | |||
If you have fixed-sized units and don't care about ordering, you eliminate external | |||
fragmentation - but you still have internal fragmentation | |||
</pre> |
Latest revision as of 22:52, 18 September 2019
Video
Video from the lecture given on September 18, 2019 is now available.
Notes
Lecture 5 --------- Assignment 1 * signals * background processes * terminal state Other stuff * assembly code * memory management Signals ------- * messages that processes can receive at any time * sent by the kernel, sometimes on behalf of other processes * (kind of like hardware interrupts) race conditions in single-threaded processes Memory management ----------------- memory can be allocated * at compile time (statically) * dynamically, on the stack * dynamically, on the heap stack ----- stack pointer = 2000 2000 2512 2004 1123 2008 4 a = 2512 b = 1123 c = 4 pop a stack pointer = 2004 2004 1123 2008 4 push d = 9999 stack pointer = 2000 2000 9999 2004 1123 2008 4 Typical memory map ffffffff command line arguments stack (grows down) heap (grows up) code 00000000 C by default doesn't have a heap - that is managed by functions in the standard library, e.g. malloc() Why is the heap such a pain to manage? - allocations aren't ordered in time - allocations aren't ordered in size Heap: Time allocated data Inital map: 0 ......11111111........2222222222222222....33333333333333. Allocate #4, size 8 1 ......11111111444444442222222222222222....33333333333333. Allocate #5, size 8 -> fail 2 ......11111111444444442222222222222222....33333333333333. Free #4 3 ......11111111........2222222222222222....33333333333333. Allocate #6, size 2 4 ......11111111...66...2222222222222222....33333333333333. This problem of lack of contiguous memory is known as fragmentation You can never escape fragmentation, but you can reduce its impact One solution: handles - pointers to pointers - advantage: memory manager can move memory - disadvantage: handles have to be dereferenced and locked before use We almost never use handles nowadays Another solution: fixed-sized allocation - always allocate storage in fixed-sized blocks - just need a way to assemble contiguous memory out of fixed-sized blocks Filesystems on disks are normally fixed-sized allocations (blocks) - have to assemble blocks together to get contigous, variable-sized storage units (e.g. files) filesystem defragmentation tries to move blocks around so files are allocated contiguous ranges of blocks internal versus external fragmentation internal: lost space inside blocks external: lost space between blocks If you have fixed-sized units and don't care about ordering, you eliminate external fragmentation - but you still have internal fragmentation