Asyncband is a collection of asynchronous synchronization primitives. Several have counterparts in tokio::sync, with different API choices; others provide additional forms of coordination. For a project already using Tokio, the practical questions are which operations have a corresponding API and which assumptions need to change.

Runtime independence is shared by both libraries. Tokio documents its synchronization primitives as runtime agnostic, with an exception for methods such as send_timeout that use its timer. Asyncband can also run on a Tokio executor. The choice of synchronization API does not by itself require a change of runtime.

An asynchronous program can start work faster than the resources behind it can handle. Downloads compete for connections and bandwidth. Background jobs compete for CPU time. Buffered data occupies memory until its consumer finishes with it. A semaphore gives these operations a shared budget: work acquires permits before consuming capacity and returns them when that capacity becomes available again.

The useful questions are what one permit represents, which operations share the budget, and how long each operation holds its permits. This post works through those choices with Asyncband's Semaphore, including how Apache OpenDAL and prek use it.