Inter Process Confusion - Navigating Zephyr's IPC APIs
summary
Zephyr gives concrete primitives and tradeoffs: k_sem is tiny and uncontended operations cost about a dozen cycles, threads are expensive (expect ~4K stack each), work queues avoid extra threads, and condition variables prevent queue-selection races. User‑space syscall overhead jumps to hundreds of cycles so kernel objects win for speed but not size. Prefer pipes or message queues for stream data, use k_event instead of complex poll when multiplexing, and never predicate blocking calls — that pattern causes bugs.
AI-written summary · about
chapters (11)
- 0:00Zephyr IPC challenges
- 7:25Uncovered Zephyr IPC APIs
- 11:12Kernel IPC primitives
- 16:29Semaphores for IPC
- 23:52Message queues tradeoffs
- 29:54Race conditions in queues
- 33:44When to use condition variables
- 34:50Threadless event handling
- 36:35User space IPC performance
- 38:59Fast user space IPC with futexes
- 40:02Final recommendations
related talks
30mCombining Zephyr & C++20 to Build Safe, Low-footprint, Event-based Applicati...
15mA Reusable Zbus Based Architecture, Abstracting Core Application...
01h 31mTutorial: Zbus - the Lightweight & Flexible Zephyr Message Bus- 15mLightning Talk: A Reusable Zbus Based Architecture, Abstracting Core Application Components
17mHow We Got DOOM Running on Zephyr (And Why You Should Try It)
44mUserspace Assisted Scheduling via Sc...
49mThinking in a Highly Concurrent, Mostly-functional Language
43mZbus 2030: Community-Driven Directions for Zbus