未验证 提交 eed36ffc 编写于 作者: A Austin 提交者: Gitee

update zh-cn/device-dev/kernel/kernel-mini-basic-ipc-event-basic.md.

Signed-off-by: NAustin <liaozhiqi7@huawei.com>
上级 31fa73dc
......@@ -29,11 +29,11 @@ typedef struct tagEvent {
### 事件运作原理<a name="section187761153144617"></a>
**事件初始化:**会创建一个事件控制块,该控制块维护一个已处理的事件集合,以及等待特定事件的任务链表。
**事件初始化**会创建一个事件控制块,该控制块维护一个已处理的事件集合,以及等待特定事件的任务链表。
**写事件:**会向事件控制块写入指定的事件,事件控制块更新事件集合,并遍历任务链表,根据任务等待具体条件满足情况决定是否唤醒相关任务。
**写事件**会向事件控制块写入指定的事件,事件控制块更新事件集合,并遍历任务链表,根据任务等待具体条件满足情况决定是否唤醒相关任务。
**读事件:**如果读取的事件已存在时,会直接同步返回。其他情况会根据超时时间以及事件触发情况,来决定返回时机:等待的事件条件在超时时间耗尽之前到达,阻塞任务会被直接唤醒,否则超时时间耗尽该任务才会被唤醒。
**读事件**如果读取的事件已存在时,会直接同步返回。其他情况会根据超时时间以及事件触发情况,来决定返回时机:等待的事件条件在超时时间耗尽之前到达,阻塞任务会被直接唤醒,否则超时时间耗尽该任务才会被唤醒。
读事件条件满足与否取决于入参eventMask和mode,eventMask即需要关注的事件类型掩码。mode是具体处理方式,分以下三种情况:
......@@ -41,9 +41,9 @@ typedef struct tagEvent {
- LOS\_WAITMODE\_OR:逻辑或,基于接口传入的事件类型掩码eventMask,只要这些事件中有任一种事件发生就可以读取成功,否则该任务将阻塞等待或者返回错误码。
- LOS\_WAITMODE\_CLR:这是一种附加读取模式,需要与所有事件模式或任一事件模式结合使用(LOS\_WAITMODE\_AND | LOS\_WAITMODE\_CLR或 LOS\_WAITMODE\_OR | LOS\_WAITMODE\_CLR)。在这种模式下,当设置的所有事件模式或任一事件模式读取成功后,会自动清除事件控制块中对应的事件类型位。
**事件清零:**根据指定掩码,去对事件控制块的事件集合进行清零操作。当掩码为0时,表示将事件集合全部清零。当掩码为0xffff时,表示不清除任何事件,保持事件集合原状。
**事件清零**根据指定掩码,去对事件控制块的事件集合进行清零操作。当掩码为0时,表示将事件集合全部清零。当掩码为0xffff时,表示不清除任何事件,保持事件集合原状。
**事件销毁:**销毁指定的事件控制块。
**事件销毁**销毁指定的事件控制块。
**图 1** 事件运作原理图<a name="fig17799175324612"></a>
![](figure/事件运作原理图.png "事件运作原理图")
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册