【鸿蒙实战开发】OpenHarmony——内核对象队列之算法详解(下)

前言

OpenAtom OpenHarmony(以下简称“OpenHarmony”) LiteOS-M 内核是面向 IoT 领域构建的轻量级物联网操作系统内核,具有小体积、低功耗、高性能的特点。在嵌入式领域的开发工作中,无论是自研还是移植系统,均绕不开内核,开发者只有掌握内核的相关知识,才能更好地深耕物联网产品领域。OpenHarmony LiteOS-M内核对象队列的算法包括FIFO和FILO,在上一期发布的《[OpenHarmony——内核对象队列之算法详解(上)文章中,我分享了OpenHarmonyLiteOS-M内核对象队列的FIFO的算法,今天给大家介绍另外一种算法——FILO算法。

关键数据结构

首先关注队列的关键数据结构LosQueueCB,有了这个数据,才能理解队列是如何工作的:

typedef struct {

*queue:指向消息节点内存区域,创建队列时按照消息节点个数乘每个节点大小从动态内存池中申请一片空间。

queueState:队列状态,表明队列控制块是否被使用,有OS_QUEUE_INUSED和OS_QUEUE_UNUSED两种状态。

queueLen:消息节点个数,表示该消息队列最大可存储多少个消息。

queueSize:每个消息节点大小,表示队列每个消息可存储信息的大小。

queueID:消息ID,通过它来操作队列。

消息节点按照循环队列的方式访问,队列中的每个节点以数组下标表示,下面的成员与消息节点循环队列有关:

queueHead:循环队列的头部。

queueTail:循环队列的尾部。

readWriteableCnt[OS_QUEUE_WRITE]:消息节点循环队列中可写的消息个数,为0表示循环队列为满,等于queueLen表示循环队列为空。

**readWriteableCnt[OS_QUEUE_READ]:**消息节点循环队列中可读的消息个数,为0表示循环队列为空,等于queueLen表示消息队列为满。 readWriteList[OS_QUEUE_WRITE]:写消息阻塞链表,链接因消息队列满而无法写入时需要挂起的TASK。

readWriteList[OS_QUEUE_READ]:读消息阻塞链表,链接因消息队列空而无法读取时需要挂起的TASK。

memList:申请内存块阻塞链表,链接因申请某一静态内存池中的内存块失败而需要挂起的TASK。</

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值