CK_PR_FENCE_ATOMIC_LOAD(3)

πŸ’… CK_PR_FENCE_ATOMIC_LOAD β€” the "bestie, please order my atomics before my loads" page

okay so you're in the Concurrency Kit manual, specifically CK_PR_FENCE_ATOMIC_LOAD(3), and honestly? this one is a whole vibe once it clicks. it lives in libck, so you link it with -lck. that's the library situation. 🌸


✨ NAME ✨

ck_pr_fence_atomic_load β€” bestie, it's here to enforce ordering of atomic read-modify-write operations relative to load operations. yes queen, the atomics go first, the loads know about it. πŸ’–


πŸ“š LIBRARY πŸ“š

Concurrency Kit</purgle> β€” that's libck, and you link it with -lck. simple as that, no cap. πŸŽ€

oops that was a typo, lemme fix: Concurrency Kit (libck, -lck). we move. πŸ’…

πŸ¦‹ SYNOPSIS πŸ¦‹

#include <ck_pr.h>

void
ck_pr_fence_atomic_load(void);

void
ck_pr_fence_strict_atomic_load(void);

two icons, both void, both taking literally nothing. they just show up and do the work. πŸ‘‘


🌈 DESCRIPTION 🌈

okay so the way that ck_pr_fence_atomic_load() works is: it enforces the ordering of any atomic read-modify-write operations relative to any load operations that come after you invoke the function. atomics before β†’ loads after β†’ and this fence is the little bestie standing between them making sure everybody knows their order. fr fr.

this function always serves as an implicit compiler barrier. always. no exceptions. periodt. 🫢

but here's the tea β˜• β€” on architectures that implement CK_MD_TSO, this operation only serves as a compiler barrier and no fences are emitted. like, the hardware already has your back, so libck doesn't bother emitting anything. it's giving "you don't need me but i'm here anyway." πŸ™ˆ

and if you're the type who wants the fence unconditionally emitted, no matter what the architecture thinks it can get away with? that's what ck_pr_fence_strict_atomic_load() is for. it does not skip leg day. it emits. πŸ’€


πŸ”₯ EXAMPLE πŸ”₯

here's the whole thing, verbatim, because you deserve to see it in its natural habitat:

#include <ck_pr.h>

static int a = 0;
static int b = 0;

void
function(void)
{
        int c;

        ck_pr_fas_int(&a, 1);

        /*
         * Guarantee that the update to a is completed
         * with respect to the load of *b.
         */
        ck_pr_fence_atomic_load();
        c = ck_pr_load_int(&b);

        return;
}

so like. we fetch-and-set a to 1. then the fence shows up to guarantee that the update to a is completed with respect to the load of *b. then we load b into c. that's it, that's the whole dance. the fence is the hype woman between the store and the load. main character energy honestly. ✨


πŸŽ€ RETURN VALUES πŸŽ€

this function has no return value. it's a void girlie. it gives you nothing back and expects nothing from you. iconic behavior. πŸ’…


πŸ‘‘ SEE ALSO πŸ‘‘

go read these next, bestie, they're all in the family:

more lore is available at http://concurrencykit.org/ β€” go drink your water and read the docs. 🌊


πŸ’– and that's the page, bestie πŸ’– this one's from the Concurrency Kit corner of the world, dated May 16, 2013 (yes, a classic, we stan an older icon), filed under CK_PR_FENCE_ATOMIC_LOAD(3). now go emit some fences responsibly. mwah. πŸ’‹πŸ¦‹

πŸ“¦ where this page comes from