ztask: 零动态分配的裸机合作式任务调度器设计分析
分析 ztask 裸机合作式调度器的设计: 静态内存池管理、基于 Tick 的排序链表调度(O(1) poll)、低功耗休眠计算。附完整 C 源码(~200 行)和典型应用示例。适用于无 RTOS 的资源受限 MCU 环境。
分析 ztask 裸机合作式调度器的设计: 静态内存池管理、基于 Tick 的排序链表调度(O(1) poll)、低功耗休眠计算。附完整 C 源码(~200 行)和典型应用示例。适用于无 RTOS 的资源受限 MCU 环境。
在轻量 RTOS 项目和嵌入式Linux中,合作式任务调度器是比操作系统线程更轻量的执行抽象。
MCCC (Message-Centric Component Communication) 消息总线的完整 API 参考,涵盖 FixedString/FixedVector 容器、MessageEnvelope 消息封装、AsyncBus 总线接口、StaticComponent 编译期组件、优先级与背压配置,每个接口附带签名、参数说明和使用示例。
以 512x512 矩阵乘法为载体,基于 newosp 基础设施库实测对比单线程、线程池、消息总线、多进程共享内存四种并行方案的性能差异,分析各方案在嵌入式 Linux 平台上的架构取舍与加速比。
在同一硬件上统一测试 MCCC、eventpp、EnTT、sigslot、ZeroMQ、QP/C++ 六个消息总线方案,从吞吐量、延迟、内存安全、嵌入式适配性四个维度给出选型建议
性能基准测试远比 ‘跑个循环、算个平均’ 复杂得多。队列溢出会虚高吞吐 30%,时钟调用本身构成 60-160% 的测量开销,功能差异让 ‘apples-to-apples’ 几乎不可能。本文从实际踩坑经验出发,系统梳理消息总线与并发数据结构基准测试中的常见陷阱与应对策略。
在嵌入式系统中,消息总线是组件间通信的核心基础设施。本文剖析 MCCC 消息总线的设计决策与工程权衡:为什么选择 Lock-free MPSC 而非互斥锁?Envelope 内嵌如何消除热路径堆分配?编译期类型索引如何替代 unordered_map?从问题出发,逐层展开一个面向安全关键嵌入式系统的消息总线的诞生过程。
在多核 ARM Linux 嵌入式系统中,同步日志的 I/O 阻塞导致控制回路超时和看门狗复位。本文设计一种基于 Per-Thread SPSC 环形缓冲与分级路由的异步日志架构,实现 wait-free 热路径 (~200-300 ns)、零竞争生产者、崩溃安全的关键日志保障。
通过逐行阅读 eventpp v0.1.3 核心代码,定位到回调遍历加锁、双锁入队、排他锁查 map 等 6 个性能瓶颈。逐一实施优化后,Active Object 吞吐量从 1.5 M/s 提升至 8.5 M/s,改善幅度超过 5 倍。最终通过 processQueueWith 编译期 Visitor 模式绕过全部 5 层间接调用,实现零开销分发 (16.7x 加速)。
死锁是嵌入式多线程系统中最隐蔽的故障之一。本文从一个典型的双锁死锁场景出发,逐步演示有序锁、lock_guard、try_lock、无锁队列四种防御策略,分析各方案在嵌入式实时系统中的工程权衡。
在嵌入式 C++ 消息总线中,std::function 回调看似方便,实则是延迟抖动和代码膨胀的隐性来源。本文分析回调链路的逐层开销,给出三个递进式优化方案:std::visit 编译期分发、CRTP 静态组件、FixedFunction 栈上类型擦除,最终在保留动态订阅能力的同时,为编译期确定的场景实现零开销分发。
基于 GCC 13 / x86-64 实测数据,面向 ARM-Linux 工业嵌入式开发者
消息总线(Message Bus)作为一种重要的通信模式,被应用于解耦系统中的组件,实现异步通信和事件驱动架构。本文介绍如何使用 C++11 实现一个基于 mutex 保护的消息总线。
对比两组实验: ARMv8 CRC32 硬件指令 (crc32cx) vs 软件查表法,以及 NEON SIMD vs 简单 C 循环的字节累加校验和。结果表明 CRC32 硬件指令比查表快 8 倍以上,而 NEON 手写的字节累加在 -O2 下反而比编译器自动优化的标量代码慢。
本文通过严格的基准测试方法,对比多线程高竞争场景下三种同步策略的性能表现:自旋锁 (atomic_flag)、互斥锁 (std::mutex) 和无锁队列 (moodycamel::ConcurrentQueue)。