Talk:Resource starvation

From Wikipedia, the free encyclopedia

Errr.. I don't get the blaming of the scheduler. Am I wrong in thinking the fault lies with the programmer whose protocol didn't account for the possibility? For example, a spinlock solution to the dining philosophers problem avoids deadlock but still has starvation - Isn't it the fault of a bad solution solution that this is possible? It seems weird trying to blame the scheduler for a lack of precognition and/or intimate knowledge of the problem that you are actually trying to solve with your code. I understand bad scheduling can cause this, but it seems somehow secondary to me right now. Delete this if I'm just not caffeinated enough:) Also, the distinction between deadlock and starvation, though technically correct, could be clearer. I'll bet a mathematician wrote that:P

Most of the time, starvation occurs as a result of two unrelated processes; the OS scheduler reliable pre-empts one of those processes in favor of the other. You can't blame the application programmer in this case, because (a) he didn't cause it, and (b) his code isn't at fault. Raul654 13:44, 26 November 2005 (UTC)

The sentence about Windows is misleading. It gives the impression that the Windows scheduler is inferior compared to other operating systems, while the real differentiation is between general-purpose systems (including Windows) and realtime systems. - Sikon 10:24, 26 January 2006 (UTC)

Seriously - many real time systems schedule the highest priority runnable thread only! That's far worse than Windows, or Linux. Windows schedules the highest priority runnable thread, but occasionally (in a random way) boosts the priority of other threads so that they will not starve completely(!). This effect can be observed when a "Realtime" process hangs (for instance Winamp, when set to use realtime-priority). The system is still usable, but mouseclicks are dispatched and windows are updated perhaps once every 10 seconds. The scheduler in Linux is much better for an interactive system, since it will effectively run threads that use little CPU (like a windowing interface) before a high-cpu task (like a hanged mp3-player). Hmm... I realize I'm rambling... --Avl 09:50, 25 March 2006 (UTC)