"Amanda Brown" <21*4*6*
1@s*u*e*t*u*a*e*u*a*> wrote:
> A question about suspend/wait state in the process life cycle.
> My understanding is when processes move to the Block/wait queue they will be present in RAM. In a situation when the RAM is full and there isn't any room for more processes, the processes need to be moved to suspend/wait queue which is held in the secondary memory. How does the OS decide which processes should go to the suspend/wait queue? And as I'm writing this I'm wondering if it is correct to say the "OS decides".
Hello Amanda,
There's no single correct answer, and it may be a property/characteristic of a particular OS, or even a configurable attribute of an OS that is read and then used after the whole OS boots.
In the 1980s and 90s there was a lot of research trying to detemine the 'right' answer, or to indicate what affects different strategies would have on performance and perceived degrees of responsiveness (for interative processes).
One obvious strategy is to take memory from the process that hasn't been running for the longest time (perhaps blocked for I/O on a very slow device, or sleeping for a very long time). But that strategy, alone, might not provide enough memory for the immediate request. So (rhetorical question), would it be best to take memory from the single process with the most memory, the process with 'just enough' memory, or from multiple processes that can (together) provide the required memory? And should we only take memory from Blocked processes, or maybe even Ready ones?
We'll discuss some of these topics and choices in lectures after the non-teaching break.
