CK_PR_FENCE_LOAD_ATOMIC(3)

✨ CK_PR_FENCE_LOAD_ATOMIC(3) ✨

okay bestie, welcome to the Concurrency Kit corner of the manual, this one lives in section 3 (that's the library-calls girlies) and it's all about making your loads behave before your atomics do their thing 💅

Part of libck, link it with -lck. Yes she's a whole library. She's that girl.

🦋 NAME 🦋

ck_pr_fence_load_atomic — enforce ordering of load operations to atomic read-modify-write operations

like. she puts your loads in their proper place before the atomic read-modify-write drama kicks off. no cap.

📚 LIBRARY 📚

Concurrency Kit (libck, -lck)

🎀 SYNOPSIS 🎀

#include <ck_pr.h>

void
ck_pr_fence_load_atomic(void);

void
ck_pr_fence_strict_load_atomic(void);

two functions, zero arguments, maximum main character energy ✨

💖 DESCRIPTION 💖

okay so here's the tea. This function enforces the ordering of any memory load and ck_pr_load(3) operations with respect to store operations relative to the invocation of the function. Translation? Your loads get told when they're allowed to show up relative to the stores. She's the group chat admin of memory ordering fr fr.

Any store operations that were committed on remote processors and received by the calling processor before the invocation of ck_pr_fence_load_atomic() is also be made visible only after a call to the ck_pr_fence_load family of functions. So like, those remote stores don't get to just barge in early — they wait their turn, bestie. 💅

This function always serves as an implicit compiler barrier. Periodt. The compiler cannot reorder across her, no matter what.

Now for the architecture lore 🧚:

• On architectures with CK_MD_TSO or CK_MD_PSO specified (total store ordering and partial store ordering respectively), this operation only serves as a compiler barrier and no fence instructions will be emitted. She's lowkey just vibing, no hardware instructions needed.
• To force the unconditional emission of a load fence, use ck_pr_fence_strict_load_atomic(). That's the version that always shows up to the party.
• Architectures implementing CK_MD_RMO always emit a fence. No exceptions, she's committed. 🔥

bestie not me warning you: if you need the fence instruction to definitely be emitted on TSO/PSO, ck_pr_fence_load_atomic() alone is not gonna do it for you. That's literally what the strict version is for. iykyk 💀

🌸 EXAMPLE 🌸

#include <ck_pr.h>

static unsigned int a;
static unsigned int b;

void
function(void)
{
        unsigned int snapshot_a, snapshot_b;

        snapshot_a = ck_pr_load_uint(&a);

        /*
         * Guarantee that the load from "a" completes
         * before the update to "b".
         */
        ck_pr_fence_load_atomic();
        ck_pr_fas_uint(&b, 1);

        return;
}

see how she sits right between the load and the ck_pr_fas_uint? that's the whole assignment. she's the bouncer between the load from a and the update to b. iconic behaviour honestly 🫶

⭐ RETURN VALUES ⭐

This function has no return value.

she gives you nothing back and honestly? that's the vibe. she did her job, she's not looking for a thank-you. 👑

🌈 SEE ALSO 🌈

the whole friend group, alphabetically chaotic:

• ck_pr_stall(3)
• ck_pr_fence_atomic(3)
• ck_pr_fence_atomic_store(3)
• ck_pr_fence_atomic_load(3)
• ck_pr_fence_load_depends(3)
• ck_pr_fence_load_store(3)
• ck_pr_fence_store(3)
• ck_pr_fence_memory(3)
• ck_pr_barrier(3)
• ck_pr_fas(3)
• ck_pr_load(3)
• ck_pr_store(3)
• ck_pr_faa(3)
• ck_pr_inc(3)
• ck_pr_dec(3)
• ck_pr_neg(3)
• ck_pr_not(3)
• ck_pr_add(3)
• ck_pr_sub(3)
• ck_pr_and(3)
• ck_pr_or(3)
• ck_pr_xor(3)
• ck_pr_cas(3)
• ck_pr_btc(3)
• ck_pr_bts(3)
• ck_pr_btr(3)

Additional information available at http://concurrencykit.org/ 🦋

and that's the whole page bestie 💖 this one was dated May 18, 2013 and comes to you from the CK_PR_FENCE_LOAD_ATOMIC(3) manual page, so if you're reading this in a terminal wondering why the fence did nothing on your TSO machine... now you know. slay responsibly. 💅✨