Jump to content

Talk:Starvation (computer science)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Comments from the Aughties

[edit]

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)[reply]
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)[reply]
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)[reply]

Not just computer science

[edit]

Starvation is an issue whenever there are concurrent jobs; it only was most thoroughly studied in computer science. There already exists a redirect resource starvation, and we have the link process starvation in Shortest job next, which is an application not limited to computers. We could express this by leaving out "In computer science" from the lede and possibly additionally by renaming the article to "resource starvation". But there is no imminent need for such changes, as any reader coming here from one of the redirects will probably have no problem transferring the concept to their field of interest. Conceivably, there could be two different articles, although I see even less need for that. Still, the redirects are useful per WP:R#KEEP7. — Sebastian 10:11, 15 January 2018 (UTC)[reply]