CK_COHORT_INIT(3)

✨ NAME ✨

CK_COHORT_INIT β€” bestie, this is the one that initializes an instance of a cohort type πŸ’–


πŸ“š LIBRARY πŸ“š

Concurrency Kit (that's libck, and you link it with -lck) 🫢


🌸 SYNOPSIS 🌸

#include <ck_cohort.h>

CK_COHORT_INIT(COHORT_NAME cohort_name, COHORT *cohort,
    void *global_lock, void *local_lock, unsigned int pass_limit);

πŸ’… DESCRIPTION πŸ’…

okay so listen, this one is important important. until you've actually initialized a cohort instance with the CK_COHORT_INIT macro, any operations involving it will have undefined behavior. like. not "oh it'll probably be fine" undefined behavior. the real kind. πŸ’€ do not skip this step, bestie, i am begging.

once you do call this macro tho? slay. the cohort pointed to by the cohort argument will use the lock pointed to by global_lock as its global lock, and the lock pointed to by local_lock as its local lock. iconic. exactly what you'd expect. ✨

now here's the juicy part πŸ“ β€” the cohort will relinquish its global lock after pass_limit consecutive acquisitions of its local lock, even if there are other threads waiting. like it just lets go. on purpose. that's the whole vibe. that's the design.

and if you're sitting there like "um what number do i put for pass_limit" πŸ™ˆ β€” no worries, if you are unsure of a value to use for the pass_limit argument, you should use CK_COHORT_DEFAULT_LOCAL_PASS_LIMIT. it's literally right there for you. use it. πŸ‘‘

fr fr: forgetting to init = undefined behavior. initializing = everything works. the choice is yours but it's not really a choice. πŸŽ€

πŸ‘€ SEE ALSO πŸ‘€

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


and that's the whole page, bestie!! this lil baddie is dated February 24, 2013, it lives in section 3 of the manual as CK_COHORT_INIT(3), and it comes to you straight from Concurrency Kit. mwah πŸ’œβœ¨

πŸ“¦ where this page comes from