3 ms·
If i'm understanding this correctly, then the difference between pre-emptive scheduling and the intermediate you described would be that in the pre-emptive sche
by booboofixer 5y ago
If i'm understanding this correctly, then the difference between pre-emptive scheduling and the intermediate you described would be that in the pre-emptive scheduling case, a poorly-behaved process would be forced to give up the CPU and then be scheduled to run again at some point in the future (in a failure state) whereas, in the intermediate solution, a poorly-behaved process would be killed and restarted.
Is that correct? If so, wouldn't this make matters worse if the poorly-behaved process is guaranteed to hang? Is killing a process and restarting it worse or better than context-switching repeatedly?
- addaon 5y agoYes, correct. Killing a process and restarting it is /often/ better than context switching repeatedly, but not always. Pro: It puts the process into a known state. Con: It removes the opportunity for slow forward progress. In the case where the process has been designed to have fixed latency, then slow forward progress is roughly as scary as memory corruption -- something is horribly wrong and you don't know if you're observing a minor symptom of a major problem. Balancing the pro/con there can be interesting, but the system level pro puts a pretty heavy thumb on the scales. In the intermediate approach, because there's no real pre-emption a whole class of race conditions can't exist. This can be pretty big for ease of system analysis.
- ir193 5y agohow about a bookmark and yield mechanism(in PL level maybe), theb process can continue slow forward process when switched back