Changes between Version 3 and Version 4 of Design
- Timestamp:
- Jun 30, 2006, 5:23:51 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Design
v3 v4 44 44 maintaining the code, but also understanding it. 45 45 46 === Schedul er adaptability===46 === Scheduling === 47 47 Designing Phase 2, we distinguished between two strictly correlated operations: scheduling and dispatching. In fact we intend the first as the action of analyzing ready processes and then choose one for execution, together with its time-quantum length. On the other hand, dispatching means to put into effect (and guarantee) that decision, that is loading the right processor state. 48 Therefore we divided them, [wiki:Architecture#a2.2.Phase2 confining] the scheduler in a '''capsule''' which obfuscates its real implementation details. This highly increase scheduler adaptability, easing future changes in every scenarios. 48 49 Therefore we divided them, [wiki:Architecture#a2.2.Phase2 confining] the '''scheduler''' in a capsule which obfuscates its real implementation details. This highly increase scheduler adaptability, easing future changes in every scenarios. 49 50 Moreover our implementation is oriented to run-time changes of scheduling algorithm, in order to provide an operating system that is ''general''-purpose and not ''generic''-purpose. 50 51 In fact the scheduler's interface consist of a series of pointers to the specific-implementation functions. They are initialized by `initSched()` according to the configuration chosen in the [source:trunk/phase2/Makefile Makefile]. 51 52 Run-time switch between scheduling algorithms can be easily implemented with a function which performs a trivial update to interface pointers and internal data structure: the ready queue. 53 54 === Dispatching === 55 We did not spend less time accurately defining interface and duties of dispatcher. In addition to the classic implementation mentioned above, we decided to request it CPU time accounting. It has to measure both direct and indirect use of the CPU. We refer to the direct use when the CPU is busied with tasks _of_ the process; indirect use qualifies the complex of tasks performed _for_ a process by the nucleus. Dispatcher itself could perform direct CPU time measure trivially, so we opted to request it also the indirect time accounting. In fact the two functions added to dispatcher interface, `play()` and `pause()`, achieve this purpose. See the diagram right above to deep understand interactions between scheduler, dispatcher and the remaining sections of the nucleus. 56 57 {{{ 58 ------------------------------------------------------------------------------ 59 | Sequence diagram of CPU usage | 60 ------------------------------------------------------------------------------ 61 62 Dispatcher Process1 Process2 SyscallH InterruptH 63 ___ . . . . 64 | . . . . execute(P1); 65 | . . . . . ._ . . . play(P1); 66 . | . . . 67 . | . . . 68 . | . . . 69 . |. . . . . . . . . . ._ . -WAITIO- 70 . . . | . suspend(P1); 71 . . . | . 72 . . . | . 73 _ . . . . . . . . . . . . . . . . .| . pause(P1); 74 | . . . . schedule(); 75 |. . . . . . . . . . . . _ . . play(P2); 76 . . | . . 77 . . | . . 78 . . | . . 79 . . | . . . . . . . . . . _ pause(P2); 80 . . . . | play(P1); 81 . . . . | wakeup(P1) 82 . . . . | pause(P1); 83 . . _ . . . . . . . . . . | play(P2); 84 . . | . . 85 . . | . . 86 . . | . . . . . . . . . . _ -INTR- 87 . . . . . . . . . . . . . . . . . . . . . . . .| dispatch() 88 _|_ . . . . 89 }}}