What is starvation?
Asked Answered
L

6

58

In multitasking systems, some abnormal conditions prevent progress of executing processes or threads. I'll refer to both processes and threads simply as "processes". Two of these conditions are called dead-lock and live-lock.

The former refers to processes which are blocking each other, thus preventing either from executing. The latter refers to processes which prevent each other from progressing, but do not actually block the execution. For instance, they might continually cause each other to rollback transactions, neither ever being able to finish them.

Another condition is known as resource starvation, in which one or more finite resources, required for the progress of the processes, have been depleted by them and can't be restored unless the processes progress. This is also a special case of live-lock.

I'd like to know if there is any other definition, particularly an academic one, for "starvation" that is not limited to "resource starvation".

Luster answered 22/7, 2009 at 1:22 Comment(2)
While you're on the subject you should also check Lock Convoys, they are very interesting. And nasty. en.wikipedia.org/wiki/Lock_convoyClayborn
Even if it was homework, it would be the best-written homework question I've ever seen on SO.Rubenstein
B
41

I wouldn't say that resource starvation is a special case of a livelock. Usually:

  • In a livelock, no thread makes progress but they keep executing. (In a deadlock, they don't even keep executing)

  • When starving, some thread(s) DO make progress and some thread(s) aren't executing.

A good explanation: http://docs.oracle.com/javase/tutorial/essential/concurrency/starvelive.html. But I understand the choice of terminology may vary.

When it comes to starvation, the definition I heard is:

Suppose it is possible to specify an infinite path of execution (interlace) consistent with assumptions (semaphore semantics, OS scheduler behaviour...) such that thread T is suspended waiting for some resource and never resumed, even if it was possible infinitely many times. Then T is called starving.

But the practice doesn't match that. Suppose two threads execute the same critical section in an infinite loop. Your synchronization code allows the first thread to enter the critical section once per hour. Is it starvation? Both threads are allowed to progress, but the first one is doing its work painfully slowly.

The simplest source of starvation are weak semaphores. If you are using a synchronization primitive (or building your own) that behaves similarly, then starvation will result.

Classical problems where starvation is well known:

For more details, I wholeheartedly recommend The Little Book of Semaphores (free): http://www.greenteapress.com/semaphores/.

You are asking if every starvation is caused by waiting for some resource. I'd say - yes.

A thread can be suspended:

(1) on some blocking system call - waiting on/acquiring a mutex, semaphore, conditional variable; write(), poll() etc.

(2) on some nonblocking operation - like performing computations.

Starving on (1) is starving on resources (mutexes, buffer etc.).

Starving on (2) is starving on CPU - you can regard it as a resource. If it happens, the problem is with scheduler.

HTH

Bondholder answered 22/7, 2009 at 2:52 Comment(0)
G
153

Imagine you're in a queue to purchase food at a restaurant, for which pregnant women have priority. And there's just a whole bunch of pregnant women arriving all the time.

You'll soon be starving. ;)

Now imagine you are a low-priority process and the pregnant women are higher priority ones. =)

Geometer answered 22/7, 2009 at 1:30 Comment(2)
ridiculous yet best explanationFrederic
Can starvation only occur when a queue is prioritized (ex by a heap) as opposed to a traditional FIFO queue? You answer I believe implies yes.Bindery
B
41

I wouldn't say that resource starvation is a special case of a livelock. Usually:

  • In a livelock, no thread makes progress but they keep executing. (In a deadlock, they don't even keep executing)

  • When starving, some thread(s) DO make progress and some thread(s) aren't executing.

A good explanation: http://docs.oracle.com/javase/tutorial/essential/concurrency/starvelive.html. But I understand the choice of terminology may vary.

When it comes to starvation, the definition I heard is:

Suppose it is possible to specify an infinite path of execution (interlace) consistent with assumptions (semaphore semantics, OS scheduler behaviour...) such that thread T is suspended waiting for some resource and never resumed, even if it was possible infinitely many times. Then T is called starving.

But the practice doesn't match that. Suppose two threads execute the same critical section in an infinite loop. Your synchronization code allows the first thread to enter the critical section once per hour. Is it starvation? Both threads are allowed to progress, but the first one is doing its work painfully slowly.

The simplest source of starvation are weak semaphores. If you are using a synchronization primitive (or building your own) that behaves similarly, then starvation will result.

Classical problems where starvation is well known:

For more details, I wholeheartedly recommend The Little Book of Semaphores (free): http://www.greenteapress.com/semaphores/.

You are asking if every starvation is caused by waiting for some resource. I'd say - yes.

A thread can be suspended:

(1) on some blocking system call - waiting on/acquiring a mutex, semaphore, conditional variable; write(), poll() etc.

(2) on some nonblocking operation - like performing computations.

Starving on (1) is starving on resources (mutexes, buffer etc.).

Starving on (2) is starving on CPU - you can regard it as a resource. If it happens, the problem is with scheduler.

HTH

Bondholder answered 22/7, 2009 at 2:52 Comment(0)
T
14

Another area where starvation or "indefinite blocking" typically comes up is when talking about Priority Scheduling algorithms. A priority scheduling algorithm has the possibility of leaving some low priority process waiting indefinitely. A steady stream of higher-priority processes can prevent a low-priority process from ever getting to run.

In case of priority schedulers, the solution is "aging". Aging is the technique of gradually increasing the priority of processes that wait in the system for a long time.

Talky answered 22/7, 2009 at 1:35 Comment(0)
R
8

Starvation is simply when a process or service is not being serve, even when there is no deadlock on the system.

This is an example I just made up just for clarification purposes.

Imagine an algorithm that control computers access to a WAN or something like that. This algorithm could have a policy that says "Provide priority access to those computers that will use less bandwidth.", that will seem like a proper policy, but then what happens when a single computer wants to access the network for an ftp upload that will send several GB somewhere. With this policy alone, that computer will starve since the algorithm will never select that computer, since there will be always other computers requesting smaller bandwidth usage.

That is called starvation.

Relentless answered 22/7, 2009 at 1:37 Comment(0)
H
1

Work is also a kind of resource. When the work distribution in a producer-consumer setup is not fair (or ideal), some threads may not get enough work items to keep them busy all the time.

Haimes answered 22/7, 2009 at 1:29 Comment(0)
A
0

A process doesn't get a resource or resources for a longer time. This is not a deadlock, because one process/s run without problem. Aging can be used to solve this problem, an aging factor is used for each request.

Assembler answered 12/7, 2015 at 6:16 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.