拓冰网站定制 
ThreadX 消息队列实战从创建到收发一次讲清线程间安全通信【免费下载链接】threadxEclipse ThreadX is an advanced real-time operating system (RTOS) designed specifically for deeply embedded applications.项目地址: https://gitcode.com/gh_mirrors/th/threadxThreadXEclipse ThreadX / Azure RTOS是面向深度嵌入式应用的实时操作系统其中的消息队列组件是线程间通信的基础设施生产者把定长数据拷进共享缓冲消费者按序取出全程由内核同步不需要应用层自己加锁。本文围绕tx_queue_create、tx_queue_send、tx_queue_receive这三个最常用的接口讲清参数含义、返回值语义和实际开发中最容易踩的几个坑。场景采集线程和数据处理线程怎么交接数据设想一个典型任务划分一个传感器采集线程以 1kHz 读取 ADC 结果另一个处理线程负责滤波和上报。如果两个线程直接读写同一个全局变量就要自己解决写了一半被读走的竞态问题如果用互斥锁则引入加解锁开销且采集线程在锁被占用时只能忙等或裸睡。ThreadX 消息队列把这两件事都封装掉了队列内部维护读写指针发送和接收都在关中断的临界区内完成多线程并发调用天然安全队列空或满时调用线程可以按wait_option挂起等待CPU 不会空转消息是定长的一次拷贝即完成交接没有额外的动态分配。图中展示了 ThreadX 各核心服务之间的关系。就消息队列这一项可以记住四个特性线程安全队列状态变更在内核临界区内进行多生产者、多消费者并发调用不会破坏数据定长缓冲每条消息占若干ULONG创建时即确定运行期零分配可阻塞等待空/满时按wait_option挂起支持超时不浪费 CPU支持插队tx_queue_front_send可把消息直接放到队头给紧急数据一条快速通道。最小可运行示例创建、发送、接收下面是一段能跑通创建 → 发送 → 接收的最小代码所有类型和常量都来自 common/inc/tx_api.h#define SENSOR_MSG_COUNT 8 /* 队列深度8 条消息 */ static ULONG sensor_buf[SENSOR_MSG_COUNT * 4]; /* 消息缓冲区8 条 x 4 个 ULONG */ static TX_QUEUE sensor_queue; /* 队列控制块 */ static VOID producer_entry(ULONG id) { ULONG sample 0x1234; while (1) { /* 队列满则最多等 20 个时钟滴答 */ UINT status tx_queue_send(sensor_queue, sample, 20); if (status TX_QUEUE_FULL) { /* 超时处理丢弃本次样本并计数 */ } tx_thread_sleep(10); } } static VOID consumer_entry(ULONG id) { ULONG sample; while (1) { /* 队列空则挂起直到收到消息永久等待 */ if (tx_queue_receive(sensor_queue, sample, TX_WAIT_FOREVER) TX_SUCCESS) { /* 处理 sample */ } } } /* 初始化阶段启动内核前 */ tx_queue_create(sensor_queue, sensor queue, TX_4_ULONG, sensor_buf, sizeof(sensor_buf));三点说明TX_QUEUE控制块和ULONG缓冲区都必须由用户提供ThreadX 不做动态内存分配TX_4_ULONG表示每条消息占 4 个ULONG8 条消息恰好填满 32 个ULONG的缓冲区容量计算见下节生产端用超时等待20 ticks而非永久等待消费者端用永久等待这是单生产者单消费者下常见且稳妥的搭配。tx_queue_create / send / receive 参数逐个讲tx_queue_create控制块、消息大小与容量怎么算UINT tx_queue_create(TX_QUEUE *queue_ptr, CHAR *name_ptr, UINT message_size, VOID *queue_start, ULONG queue_size);参数说明queue_ptr队列控制块指针未初始化即可函数内部会清零并登记name_ptr队列名字符串仅用于调试和tx_queue_info_get查询message_size单条消息占用的ULONG个数常用TX_1_ULONG、TX_2_ULONG、TX_4_ULONG等预定义常量queue_start消息缓冲区起始地址通常是一个静态ULONG数组queue_size缓冲区总字节数容量由内核计算capacity queue_size / (message_size * sizeof(ULONG))即总字节数除以单条消息字节数。这里有两个约束必须满足message_size以ULONG为单位不能直接传字节数queue_size若不是单条消息字节的整数倍余数部分直接浪费深度只按整除结果计算。该函数总是返回TX_SUCCESS成功与否主要取决于你传入的参数是否自洽。tx_queue_send 与 tx_queue_receivewait_option 的三种取值UINT tx_queue_send(TX_QUEUE *queue_ptr, VOID *source_ptr, ULONG wait_option); UINT tx_queue_receive(TX_QUEUE *queue_ptr, VOID *destination_ptr, ULONG wait_option);两个函数的参数对称source_ptr/destination_ptr指向一条消息大小的数据区wait_option决定阻塞行为wait_option取值行为TX_NO_WAIT值为 0立即检查队满/队空直接返回错误不挂起TX_WAIT_FOREVER挂起直到成功永不超时正整数最多挂起 N 个时钟滴答超时返回对应错误返回值对照返回值含义TX_SUCCESS消息发送/接收成功TX_QUEUE_FULL队列已满TX_NO_WAIT直接返回或等待超时发送端TX_QUEUE_EMPTY队列为空TX_NO_WAIT直接返回或等待超时接收端TX_WAIT_ABORTED等待期间被tx_thread_wait_abort中止内核 6.x 提供一个容易被忽略的细节tx_queue_send传入的指针必须指向至少message_size个ULONG的内存tx_queue_receive的destination_ptr同理。缓冲区小于消息大小时内核不会做保护数据会直接写越界。队列满了或空了怎么办队满时阻塞发送是默认解法但别用死等现象生产者跑得快tx_queue_send频繁返回TX_QUEUE_FULL。原因消费者处理速度跟不上生产速度队列深度不足以吸收突发。处理把wait_option从TX_NO_WAIT换成超时值线程在队满时挂起等接收腾出槽位后由内核自动恢复消息随后入队无需轮询。注意生产端慎用TX_WAIT_FOREVER如果消费者逻辑上可能长期不取消息比如进入低功耗状态生产者会被永久挂死。超时返回TX_QUEUE_FULL后再决定是丢弃、计数还是写入备用缓冲。队空时接收端挂起等待CPU 零开销现象用TX_NO_WAIT轮询接收忙等空转CPU 占用高。原因TX_NO_WAIT适合顺手取一下的场景不适合把接收作为线程的主循环。处理主循环中用TX_WAIT_FOREVER或带超时的wait_option队列空时线程挂起来消息的瞬间被内核恢复。若需要周期性地做其他工作如喂看门狗就用超时值收到TX_QUEUE_EMPTY后继续做杂务。紧急消息插队tx_queue_front_send普通发送永远排在队尾FIFO。当某条消息要求尽快被处理时用tx_queue_front_send(sensor_queue, urgent, TX_WAIT_FOREVER);它把消息直接放到队头下一个tx_queue_receive会先取到它。注意两点插队对所有等待该队列的接收者生效同一条队列里若普通消息和紧急消息语义不同建议分设两条队列避免紧急消息被普通消息淹没或干扰处理分支。行为不对时用 tx_queue_info_get 诊断现象吞吐莫名下降或怀疑某端卡死。原因不知道当前队列里积压了多少、有多少线程在等。处理CHAR *name; ULONG enqueued, available, suspended; TX_THREAD *first; TX_QUEUE *next; tx_queue_info_get(sensor_queue, name, enqueued, available, first, suspended, next);拿到enqueued已入队消息数、available剩余容量、suspended挂起线程数三个数就能定位大多数问题enqueued长期贴着容量说明消费慢suspended里有接收线程说明只是暂时没数据enqueued为 0 且有大量发送线程挂起则更奇怪值得深挖。定位后若确认是吞吐问题可再启用 ThreadX 的性能统计接口tx_queue_performance_info_get见 common/inc/tx_queue.h查看各队列的发送/接收计数与超时次数。避坑清单易错点后果建议不检查返回值丢弃消息、空转问题难以复现每次tx_queue_send/tx_queue_receive后判断TX_SUCCESS以外的分支生产端用TX_WAIT_FOREVER消费者异常时生产者永久挂死生产端默认用超时值保留可恢复的失败路径缓冲区总字节数算错队列深度比预期小queue_size必须是message_size * sizeof(ULONG)的整数倍按条数 × 每条字节数推导destination_ptr小于消息大小写越界、数据错乱难排查接收/发送缓冲区按消息大小声明别用局部小变量用队列传变长数据越界或只拷贝了一半队列只传定长结构体或指针变长内容放堆外缓冲并另行管理生命周期删除队列前未 flush消息被意外丢弃或状态不一致tx_queue_delete前确认无线程挂起必要时先tx_queue_flush清空积压延伸阅读与下一步API 头文件common/inc/tx_api.h队列 API 声明与全部返回值常量、common/inc/tx_queue.hTX_QUEUE结构体与控制块字段官方示例samples/demo_threadx.c含队列、信号量等服务的完整用法内核实现common/src/tx_queue_send.c、common/src/tx_queue_receive.c对照源码读一遍挂起/恢复路径比只看文档更扎实下一步建议先把samples/demo_threadx.c在 Linux 端口ports/linux下编译跑通观察队列创建到收发的完整流程给自己的系统加一个诊断接口定期调用tx_queue_info_get输出enqueued和suspended作为日后排查通信问题的基线数据需要消息到达通知或消费侧解耦时再研究tx_queue_send_notify回调和事件标志的组合用法。【免费下载链接】threadxEclipse ThreadX is an advanced real-time operating system (RTOS) designed specifically for deeply embedded applications.项目地址: https://gitcode.com/gh_mirrors/th/threadx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ThreadX 消息队列实战：从创建到收发，一次讲清线程间安全通信
ThreadX 消息队列实战从创建到收发一次讲清线程间安全通信【免费下载链接】threadxEclipse ThreadX is an advanced real-time operating system (RTOS) designed specifically for deeply embedded applications.项目地址: https://gitcode.com/gh_mirrors/th/threadxThreadXEclipse ThreadX / Azure RTOS是面向深度嵌入式应用的实时操作系统其中的消息队列组件是线程间通信的基础设施生产者把定长数据拷进共享缓冲消费者按序取出全程由内核同步不需要应用层自己加锁。本文围绕tx_queue_create、tx_queue_send、tx_queue_receive这三个最常用的接口讲清参数含义、返回值语义和实际开发中最容易踩的几个坑。场景采集线程和数据处理线程怎么交接数据设想一个典型任务划分一个传感器采集线程以 1kHz 读取 ADC 结果另一个处理线程负责滤波和上报。如果两个线程直接读写同一个全局变量就要自己解决写了一半被读走的竞态问题如果用互斥锁则引入加解锁开销且采集线程在锁被占用时只能忙等或裸睡。ThreadX 消息队列把这两件事都封装掉了队列内部维护读写指针发送和接收都在关中断的临界区内完成多线程并发调用天然安全队列空或满时调用线程可以按wait_option挂起等待CPU 不会空转消息是定长的一次拷贝即完成交接没有额外的动态分配。图中展示了 ThreadX 各核心服务之间的关系。就消息队列这一项可以记住四个特性线程安全队列状态变更在内核临界区内进行多生产者、多消费者并发调用不会破坏数据定长缓冲每条消息占若干ULONG创建时即确定运行期零分配可阻塞等待空/满时按wait_option挂起支持超时不浪费 CPU支持插队tx_queue_front_send可把消息直接放到队头给紧急数据一条快速通道。最小可运行示例创建、发送、接收下面是一段能跑通创建 → 发送 → 接收的最小代码所有类型和常量都来自 common/inc/tx_api.h#define SENSOR_MSG_COUNT 8 /* 队列深度8 条消息 */ static ULONG sensor_buf[SENSOR_MSG_COUNT * 4]; /* 消息缓冲区8 条 x 4 个 ULONG */ static TX_QUEUE sensor_queue; /* 队列控制块 */ static VOID producer_entry(ULONG id) { ULONG sample 0x1234; while (1) { /* 队列满则最多等 20 个时钟滴答 */ UINT status tx_queue_send(sensor_queue, sample, 20); if (status TX_QUEUE_FULL) { /* 超时处理丢弃本次样本并计数 */ } tx_thread_sleep(10); } } static VOID consumer_entry(ULONG id) { ULONG sample; while (1) { /* 队列空则挂起直到收到消息永久等待 */ if (tx_queue_receive(sensor_queue, sample, TX_WAIT_FOREVER) TX_SUCCESS) { /* 处理 sample */ } } } /* 初始化阶段启动内核前 */ tx_queue_create(sensor_queue, sensor queue, TX_4_ULONG, sensor_buf, sizeof(sensor_buf));三点说明TX_QUEUE控制块和ULONG缓冲区都必须由用户提供ThreadX 不做动态内存分配TX_4_ULONG表示每条消息占 4 个ULONG8 条消息恰好填满 32 个ULONG的缓冲区容量计算见下节生产端用超时等待20 ticks而非永久等待消费者端用永久等待这是单生产者单消费者下常见且稳妥的搭配。tx_queue_create / send / receive 参数逐个讲tx_queue_create控制块、消息大小与容量怎么算UINT tx_queue_create(TX_QUEUE *queue_ptr, CHAR *name_ptr, UINT message_size, VOID *queue_start, ULONG queue_size);参数说明queue_ptr队列控制块指针未初始化即可函数内部会清零并登记name_ptr队列名字符串仅用于调试和tx_queue_info_get查询message_size单条消息占用的ULONG个数常用TX_1_ULONG、TX_2_ULONG、TX_4_ULONG等预定义常量queue_start消息缓冲区起始地址通常是一个静态ULONG数组queue_size缓冲区总字节数容量由内核计算capacity queue_size / (message_size * sizeof(ULONG))即总字节数除以单条消息字节数。这里有两个约束必须满足message_size以ULONG为单位不能直接传字节数queue_size若不是单条消息字节的整数倍余数部分直接浪费深度只按整除结果计算。该函数总是返回TX_SUCCESS成功与否主要取决于你传入的参数是否自洽。tx_queue_send 与 tx_queue_receivewait_option 的三种取值UINT tx_queue_send(TX_QUEUE *queue_ptr, VOID *source_ptr, ULONG wait_option); UINT tx_queue_receive(TX_QUEUE *queue_ptr, VOID *destination_ptr, ULONG wait_option);两个函数的参数对称source_ptr/destination_ptr指向一条消息大小的数据区wait_option决定阻塞行为wait_option取值行为TX_NO_WAIT值为 0立即检查队满/队空直接返回错误不挂起TX_WAIT_FOREVER挂起直到成功永不超时正整数最多挂起 N 个时钟滴答超时返回对应错误返回值对照返回值含义TX_SUCCESS消息发送/接收成功TX_QUEUE_FULL队列已满TX_NO_WAIT直接返回或等待超时发送端TX_QUEUE_EMPTY队列为空TX_NO_WAIT直接返回或等待超时接收端TX_WAIT_ABORTED等待期间被tx_thread_wait_abort中止内核 6.x 提供一个容易被忽略的细节tx_queue_send传入的指针必须指向至少message_size个ULONG的内存tx_queue_receive的destination_ptr同理。缓冲区小于消息大小时内核不会做保护数据会直接写越界。队列满了或空了怎么办队满时阻塞发送是默认解法但别用死等现象生产者跑得快tx_queue_send频繁返回TX_QUEUE_FULL。原因消费者处理速度跟不上生产速度队列深度不足以吸收突发。处理把wait_option从TX_NO_WAIT换成超时值线程在队满时挂起等接收腾出槽位后由内核自动恢复消息随后入队无需轮询。注意生产端慎用TX_WAIT_FOREVER如果消费者逻辑上可能长期不取消息比如进入低功耗状态生产者会被永久挂死。超时返回TX_QUEUE_FULL后再决定是丢弃、计数还是写入备用缓冲。队空时接收端挂起等待CPU 零开销现象用TX_NO_WAIT轮询接收忙等空转CPU 占用高。原因TX_NO_WAIT适合顺手取一下的场景不适合把接收作为线程的主循环。处理主循环中用TX_WAIT_FOREVER或带超时的wait_option队列空时线程挂起来消息的瞬间被内核恢复。若需要周期性地做其他工作如喂看门狗就用超时值收到TX_QUEUE_EMPTY后继续做杂务。紧急消息插队tx_queue_front_send普通发送永远排在队尾FIFO。当某条消息要求尽快被处理时用tx_queue_front_send(sensor_queue, urgent, TX_WAIT_FOREVER);它把消息直接放到队头下一个tx_queue_receive会先取到它。注意两点插队对所有等待该队列的接收者生效同一条队列里若普通消息和紧急消息语义不同建议分设两条队列避免紧急消息被普通消息淹没或干扰处理分支。行为不对时用 tx_queue_info_get 诊断现象吞吐莫名下降或怀疑某端卡死。原因不知道当前队列里积压了多少、有多少线程在等。处理CHAR *name; ULONG enqueued, available, suspended; TX_THREAD *first; TX_QUEUE *next; tx_queue_info_get(sensor_queue, name, enqueued, available, first, suspended, next);拿到enqueued已入队消息数、available剩余容量、suspended挂起线程数三个数就能定位大多数问题enqueued长期贴着容量说明消费慢suspended里有接收线程说明只是暂时没数据enqueued为 0 且有大量发送线程挂起则更奇怪值得深挖。定位后若确认是吞吐问题可再启用 ThreadX 的性能统计接口tx_queue_performance_info_get见 common/inc/tx_queue.h查看各队列的发送/接收计数与超时次数。避坑清单易错点后果建议不检查返回值丢弃消息、空转问题难以复现每次tx_queue_send/tx_queue_receive后判断TX_SUCCESS以外的分支生产端用TX_WAIT_FOREVER消费者异常时生产者永久挂死生产端默认用超时值保留可恢复的失败路径缓冲区总字节数算错队列深度比预期小queue_size必须是message_size * sizeof(ULONG)的整数倍按条数 × 每条字节数推导destination_ptr小于消息大小写越界、数据错乱难排查接收/发送缓冲区按消息大小声明别用局部小变量用队列传变长数据越界或只拷贝了一半队列只传定长结构体或指针变长内容放堆外缓冲并另行管理生命周期删除队列前未 flush消息被意外丢弃或状态不一致tx_queue_delete前确认无线程挂起必要时先tx_queue_flush清空积压延伸阅读与下一步API 头文件common/inc/tx_api.h队列 API 声明与全部返回值常量、common/inc/tx_queue.hTX_QUEUE结构体与控制块字段官方示例samples/demo_threadx.c含队列、信号量等服务的完整用法内核实现common/src/tx_queue_send.c、common/src/tx_queue_receive.c对照源码读一遍挂起/恢复路径比只看文档更扎实下一步建议先把samples/demo_threadx.c在 Linux 端口ports/linux下编译跑通观察队列创建到收发的完整流程给自己的系统加一个诊断接口定期调用tx_queue_info_get输出enqueued和suspended作为日后排查通信问题的基线数据需要消息到达通知或消费侧解耦时再研究tx_queue_send_notify回调和事件标志的组合用法。【免费下载链接】threadxEclipse ThreadX is an advanced real-time operating system (RTOS) designed specifically for deeply embedded applications.项目地址: https://gitcode.com/gh_mirrors/th/threadx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考