qthread_syncvar_writeEF(3)

πŸ“¦ version 1.22^20251007gitcedb1fc, in fedora 43, fedora 44

πŸ’– NAME πŸ’–

qthread_syncvar_writeEF, qthread_syncvar_writeEF_const β€” bestie, these ones wait for the dest syncvar to be empty, and then they fill it πŸ’…

(they live in libqthread, in case you were wondering πŸ¦‹)


🌸 SYNOPSIS 🌸

#include <qthread.h>

int
qthread_syncvar_writeEF (syncvar_t * restrict dest, const uint64_t *
restrict src);

int
qthread_writeEF_const (syncvar_t *dest, uint64_t src);

✨ DESCRIPTION ✨

okay so here's the vibe: these functions wait for the dest syncvar to become empty, and then they fill it. that's it, that's the whole personality 🫢

and when dest does finally go empty? only one thread that's blocked like this gets awoken. not two, not the whole group chat. one. no cap.

data is read from src and written to dest. and lowkey important: the data in src MUST be small enough to fit in the syncvar_t. it's giving "measure twice, write once" 😭

the semantics of writeEF are, in order, bestie:

  1. dest's FEB state must be "empty"
  2. data is copied from src to dest
  3. dest's FEB state gets changed from "empty" to "full"

periodt. πŸ’…


πŸ‘‘ RETURN VALUE πŸ‘‘

on success: the memory address dest is marked full, the address dest is filled with the contents of src, and 0 (QTHREAD_SUCCESS) is returned. slay ✨

on error: a non-zero error code comes back at you. not slay. πŸ’€


πŸŽ€ ERRORS πŸŽ€

  • ENOMEM β€” not enough memory could be allocated for bookkeeping structures (when blocking). the bookkeeping said "no thoughts, head empty" πŸ™ˆ
  • EOVERFLOW β€” the value specified in src could not be stored in the syncvar_t. on most platforms, syncvar_t can only store 60 bits of data, despite occupying 64 bits of memory, because four bits are reserved for status information. so yeah, it's a 64-bit outfit with only 60 bits of pocket space 🫠
  • QTHREAD_TIMEOUT β€” could not obtain the lock on the syncvar_t's status bits. this may be caused by many things, including memory corruption, invalid syncvar, or even absurdly excessive contention (because its protected by a naive spinlock rather than a fair spinlock). so basically: it could be a little oopsie or it could be the whole thing falling apart 🚨

πŸ”₯ SEE ALSO πŸ”₯


libqthread Β· APRIL 2011 Β· qthread_syncvar_writeEF(3)

and that's the whole page, bestie πŸ’– go forth and fill your syncvars, stay hydrated, and remember: only one thread gets woken up, so don't be weird about it 🧚✨

πŸ“¦ where this page comes from