CK_EPOCH_BARRIER(3)
β¨ ck_epoch_barrier(3) β¨
okay bestie, buckle up π this is ck_epoch_barrier from the Concurrency Kit β that's libck, and you link it with -lck. it's giving "wait for the vibes to settle before you delete anything" and honestly? iconic. π
πΈ SYNOPSIS πΈ
#include <ck_epoch.h>
void
ck_epoch_barrier(ck_epoch_record_t *record);
π DESCRIPTION π
so ck_epoch_barrier(3) is the "hold up, let's all calm down" function π«Ά. it blocks the caller until a grace period has been detected, following the rules of epoch reclamation. what does that mean for you? it means any object that needs safe memory reclamation and has been logically deleted is now safe for physical deletion once you've called ck_epoch_barrier(3). no cap. π₯
and that's not even all of it β this function will also dispatch all the callbacks associated with epoch that you'd previously scheduled with ck_epoch_call(3). two for one, we love an efficient queen. π
π¦ EXAMPLE π¦
#include <ck_epoch.h>
#include <ck_stack.h>
#include <stdlib.h>
/*
* epoch was previously initialized with ck_epoch_init.
* stack was previously initialized with ck_stack_init.
*/
ck_epoch_t *epoch;
ck_stack_t *stack;
void
function(void)
{
ck_epoch_record_t *record;
ck_stack_entry_t *s;
record = malloc(sizeof *record);
ck_epoch_register(&epoch, record, NULL);
/*
* We are using an epoch section here to guarantee no
* nodes in the stack are deleted while we are dereferencing
* them. This is needed here because there are multiple writers.
* If there was only one thread popping from the this stack,
* then there is no need to ck_epoch_begin/ck_epoch_end.
*/
ck_epoch_begin(record);
/* Logically delete an object. */
s = ck_stack_pop_upmc(stack);
ck_epoch_end(record);
/*
* Wait until no threads could possibly have a reference to the
* object we just popped (assume all threads are simply executing
* ck_stack_pop_upmc).
*/
ck_epoch_barrier(record);
/* It is now safe to physically delete the object. */
free(s);
return;
}
β RETURN VALUES β
this one has no return value. she simply does the thing and leaves. periodt. π
π ERRORS π
behavior is undefined if the object pointed to byepochis not a valid epoch object π like, genuinely undefined, not in a cute way. also, the object pointed to byrecordmust have been previously registered viack_epoch_register(3). don't skip that step bestie, it's not optional. π¨
π SEE ALSO π
ck_epoch_init(3)ck_epoch_register(3)ck_epoch_unregister(3)ck_epoch_recycle(3)ck_epoch_poll(3)ck_epoch_synchronize(3)ck_epoch_reclaim(3)ck_epoch_call(3)ck_epoch_begin(3)ck_epoch_end(3)
more info lives at http://concurrencykit.org/ β¨ go read it, i'll wait π
and that's the whole page!! π§ this edition was dated September 2, 2012 and it's filed under CK_EPOCH_BARRIER(3) β slay, bye bestie! ππ
π¦ where this page comes from
- alpine 3.24: ck-doc 0.7.2-r1 Β· BSD-2-Clause AND Apache-2.0
- debian trixie: libck-dev 0.7.2-6 Β· BSD-2-Clause
- epel 10: ck-devel 0.7.2-1.el10_1 Β· BSD-2-clause AND Apache-2.0 AND BSD-3-clause
- fedora 43: ck-devel 0.7.2-2.fc43 Β· BSD-2-clause AND Apache-2.0 AND BSD-3-clause
- fedora 43: ck-devel 0.7.2-2.fc43 Β· BSD-2-clause AND Apache-2.0 AND BSD-3-clause
- fedora 44: ck-devel 0.7.2-4.fc44 Β· BSD-2-clause AND Apache-2.0 AND BSD-3-clause
- fedora 44: ck-devel 0.7.2-4.fc44 Β· BSD-2-clause AND Apache-2.0 AND BSD-3-clause
- nixos 26.05: ck 0.7.2
- nixpkgs unstable: ck 0.7.2
- opensuse-leap 16.0: ck-devel 0.7.2-bp160.1.9 Β· Apache-2.0 AND BSD-2-Clause
- opensuse-leap 16.0: ck-devel 0.7.2-bp160.1.9 Β· Apache-2.0 AND BSD-2-Clause
- opensuse-leap 16.0: ck-devel 0.7.2-bp160.1.9 Β· Apache-2.0 AND BSD-2-Clause
- ubuntu questing: libck-dev 0.7.2-5ubuntu1
- ubuntu resolute: libck-dev 0.7.2-5ubuntu2 Β· BSD-2-Clause
- ubuntu stonking: libck-dev 0.7.2-11 Β· BSD-2-Clause
- Copyright 2012-2013 Samy Al Bahra
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms