REFCOUNT(9)

πŸ“¦ version 15.1, in freebsd 14.5, freebsd 15.1

πŸ’– refcount(9) β€” manage a simple reference counter πŸ’–

okay bestie, welcome to the refcount(9) page from the Kernel Developer's Manual. This is the whole lowdown on a simple reference counter: no cap, just a bunch of static inline helpers and some very real synchronization tea β˜•πŸ’….


✨ NAME ✨

refcount, refcount_init, refcount_acquire, refcount_release β€” manage a simple reference counter.

(yes, the synopsis down there is longer β€” we love a little cast expansion 🫢)

✨ SYNOPSIS ✨

#include <sys/param.h>
#include <sys/refcount.h>

void
refcount_init(volatile u_int *count, u_int value);

u_int
refcount_load(volatile u_int *count);

u_int
refcount_acquire(volatile u_int *count);

bool
refcount_acquire_checked(volatile u_int *count);

bool
refcount_acquire_if_not_zero(volatile u_int *count);

bool
refcount_release(volatile u_int *count);

bool
refcount_release_if_last(volatile u_int *count);

bool
refcount_release_if_not_last(volatile u_int *count);

πŸ¦‹ DESCRIPTION πŸ¦‹

The refcount functions are the API for managing a simple reference counter. You, the caller, bring the storage: it's an unsigned integer, and you pass a pointer to it via count. Usually this counter is managing the lifetime of an object and lives as a member of that object β€” main character counter energy, honestly πŸ‘‘.

Currently all functions are implemented as static inline β€” tiny, inline, and ready to go.

πŸ’… the functions, one by one πŸ’…

  • refcount_init() β€” sets the initial value of the counter to value. It's normally used when you're creating a reference-counted object. Fresh object, fresh count, slay ✨.
  • refcount_load() β€” returns a snapshot of the counter value. Heads up: that value may immediately become out-of-date in the absence of external synchronization. Use refcount_load() instead of relying on the properties of the volatile qualifier. It's giving β€œtrust the function, not the qualifier” 😌.
  • refcount_acquire() β€” acquires a new reference. It returns the counter value before the new reference was acquired. The caller is responsible for ensuring it holds a valid reference while obtaining a new reference. Example time: if an object is stored on a list and the list holds a reference on the object, then holding a lock that protects the list provides sufficient protection for acquiring a new reference. Locked and loaded, bestie πŸ”’.
  • refcount_acquire_checked() β€” same operation as refcount_acquire(), but it additionally checks that the count value does not overflow as a result of the operation. It returns true if the reference was successfully obtained, and false if it was not, due to the overflow. Overflow said β€œnot today” πŸ’€.
  • refcount_acquire_if_not_zero() β€” yet another refcount_acquire() variant. It only obtains the reference when some reference already exists. In other words, *count must already be greater than zero for the function to succeed; then the return value is true, otherwise false is returned. Zero count? No reference for you πŸ™ˆ.
  • refcount_release() β€” releases an existing reference. It returns true if the reference being released was the last reference; otherwise, it returns false. Last one out gets the true, periodt πŸ’….
  • refcount_release_if_last() and refcount_release_if_not_last() β€” variants of refcount_release() that only drop the reference when it is or is not the last reference, respectively. In other words, refcount_release_if_last() returns true when *count is equal to one, in which case it is decremented to zero. Otherwise, *count is not modified and the function returns false. Similarly, refcount_release_if_not_last() returns true when *count is greater than one, in which case *count is decremented. Otherwise, if *count is equal to one, the reference is not released and the function returns false. Conditional release, conditional vibes πŸ¦‹.
⚠️ Big caveat, no cap: these routines do not provide any inter-CPU synchronization or data protection for managing the counter. The caller is responsible for any additional synchronization needed by consumers of any containing objects. The caller is also responsible for managing the life cycle of any containing objects, including explicitly releasing any resources when the last reference is released. You are the main character of cleanup here 🫢.

And one more very important fence note: refcount_release() unconditionally executes a release fence (see atomic(9)) before releasing the reference, which synchronizes with an acquire fence executed right before returning the true value. This ensures that the destructor β€” supposedly executed by the caller after the last reference was dropped β€” sees all updates done during the lifetime of the object. Fence drama, but make it synchronized ⚑.

πŸŽ€ RETURN VALUES πŸŽ€

The refcount_release function returns true when releasing the last reference and false when releasing any other reference. That's the return-value tea, and it's piping hot β˜•.

🌸 HISTORY 🌸

These functions were introduced in FreeBSD 6.0. Vintage but still iconic πŸŽ€.


okay that's the whole page, bestie 🫢 β€” mwah πŸ’‹, and this little icon was brought to you by the Debian version dated October 12, 2022 ✨.

πŸ“¦ where this page comes from