aging
Imagine a deli counter that, to be fair, slips you a slightly better number for every minute you have waited — wait long enough and even a humble order rises to the front. Aging is exactly that trick applied to priorities: the longer a process has been waiting in the ready queue, the more its effective priority is gradually increased, so no one waits forever.
How it works: the scheduler periodically bumps up the priority of every process that has been waiting, by a small amount per time interval. A low-priority job that would otherwise be perpetually outranked slowly climbs; after enough waiting its boosted priority eventually exceeds that of the newcomers, and it finally gets the CPU. Once it runs, its priority can be reset to its base level. The rate of aging is a tuning knob — too slow and starvation is barely relieved, too fast and the original priorities lose meaning.
Why it matters: aging is the standard, simple cure for starvation in priority-based scheduling, and the same idea reappears across operating systems wherever a fixed priority could leave someone stuck. It converts an unbounded wait into a bounded one — the guarantee that you will eventually run — without throwing away the benefits of priorities most of the time. It is a small mechanism with an outsized role in making priority scheduling actually usable.
A job starts at priority 10 (low). Aging adds 1 to its priority for every 5 ms it waits. After enough waiting its number climbs above the busy stream of priority-2 jobs, so it finally gets scheduled — bounding its wait instead of letting it starve forever.
Aging steadily lifts a long-waiting job's priority until it must eventually run.
Aging here (raising priority over waiting time) is a SCHEDULING cure for starvation; do not confuse it with the page-replacement aging algorithm, which is an entirely different mechanism using reference bits.