Resource Accounting

Resource Accounting: Preventing Starvation

In this lesson, you will learn how to implement strict resource accounting to prevent a single subsystem from monopolizing system capacity and causing starvation across your application.

When building high-performance Rust systems, simply relying on OS-level thread scheduling or global locks is rarely enough. If one component—such as an image processing task or an API handler—begins to consume all available memory or CPU cycles, it can induce "latency jitter" or complete starvation for other, more critical components. Resource accounting is the practice of imposing a "budget" on each thread or subsystem, forcing them to pause or shed load when they exceed their predefined allocation.

Implementation via Token Buckets and Counters

The most robust way to handle this in Rust is by using an atomic-backed accounting structure that tasks must check before spawning work or allocating memory. By utilizing std::sync::atomic, we can track usage without the overhead of heavy locks.

use std::sync::atomic::{AtomicUsize, Ordering};

struct ResourceQuota {
    limit: usize,
    used: AtomicUsize,
}

impl ResourceQuota {
    fn try_allocate(&self, amount: usize) -> bool {
        let current = self.used.load(Ordering::Relaxed);
        if current + amount > self.limit {
            false
        } else {
            self.used.fetch_add(amount, Ordering::SeqCst);
            true
        }
    }

    fn release(&self, amount: usize) {
        self.used.fetch_sub(amount, Ordering::SeqCst);
    }
}

In this pattern, a subsystem must request an "allocation" from its assigned ResourceQuota before proceeding. If try_allocate returns false, the subsystem must trigger its Graceful Degradation logic (Lesson 14) or apply Backpressure (Lesson 25) to slow down its intake.

By integrating this with Metrics Exportation (Lesson 9), you can monitor these counters in real-time, allowing your Configuration Management (Lesson 10) layer to dynamically adjust limits if a subsystem is consistently being starved or hitting its ceiling unnecessarily. This ensures your system remains responsive even under heavy, imbalanced loads.

Key Takeaway: Implement atomic-based per-subsystem quotas to enforce strict resource boundaries, forcing components to throttle their own activity before they compromise the stability of the entire system.