CN108958904A

CN108958904A - 嵌入式多核中央处理器的轻量级操作系统的驱动程序框架

Info

Publication number: CN108958904A
Application number: CN201710380325.0A
Authority: CN
Inventors: 路向峰; 王树柯
Original assignee: Beijing Memblaze Technology Co Ltd
Current assignee: Beijing Memblaze Technology Co Ltd
Priority date: 2017-05-25
Filing date: 2017-05-25
Publication date: 2018-12-07
Anticipated expiration: 2037-05-25
Also published as: CN108958904B

Abstract

本申请公开了嵌入式多核中央处理器的轻量级操作系统的驱动程序框架。利用所公开的嵌入式多核中央处理器的轻量级操作系统的驱动程序框架进行任务处理方法包括：注册第一类用于接收消息的处理函数，第一类用于接收消息的处理函数用于接收第一消息以发起对第一任务的处理；响应于接收第一消息，注册第一类用于发送消息的处理函数指示发送第二消息以继续对所述第一任务的处理；以及注册第二类用于接收消息的处理函数，第二类用于接收消息的处理函数用于接收第三消息以结束对所述第一任务的处理。

Description

嵌入式多核中央处理器的轻量级操作系统的驱动程序框架

技术领域

本申请涉及嵌入式多核中央处理器的轻量级操作系统的驱动程序框架，尤其涉及对嵌入式多核中央处理器上处理的任务的调度。

背景技术

嵌入式多核CPU(中央处理器，Central Processing Unit)的各个核处理各自的任务。CPU的各个核之间有对通信、协同的大量需求。任务之间有顺序性，一项任务的开始依赖于在前的一个或多个任务的处理完成。CPU的各个核处理多种事件，依据事件知晓在前任务的处理进度。例如，事件包括队列中出现待处理的条目、指定长度时间的流逝、中断、处理任务过程中产生的自定义事件等。

图1是现有技术的嵌入式多核CPU系统的框图。CPU 0与CPU 1为同构或异构的CPU核，通过总线相耦合。每个CPU具有本地存储器，CPU可低延迟地访问自己的本地存储器。CPU还通过总线耦合到外部存储器，例如DDR(Dual Data Rate，双倍速率)存储器。外部存储器提供大的存储容量，但访问延迟较高。因此，CPU访问外部存储器时，通常通过队列来缓存高延迟的命令。命令的形式可以是具有指定数据格式的消息。

队列的条目是消息。CPU从入站队列接收消息，而通过出站队列发送消息。CPU可拥有多种数量的队列。示例性地，参看图1，CPU 0包括入站(Inbound)队列0、入站(Inbound)队列1、出站(Outbound)队列0与出站(Outbound)队列1。

为访问外部存储器，CPU 0向出站队列0添加消息。消息被总线转发给外部存储器。外部存储器输出存储器访问结果，通过总线转发给入站队列0。

CPU之间通过队列交换消息。例如，CPU 0向出战队列1添加消息。消息被总线转发给CPU 1的入站队列0。CPU 1从入站队列0获取CPU 0发送的消息。

发明内容

以访问外部存储器为例，CPU向出站队列添加消息需检查队列状态，并在出站队列未满时进行操作，而从CPU向出站队列添加访问外部存储器的消息，到CPU从入站队列接收外部存储器的访问结果之间，有较长的时间。在等待入站队列变为非空，或者等待访问外部存储器的结果这段时间，CPU需要调度处理其他任务来提升CPU利用率。当CPU同时处理多个相同或不同任务、使用多个队列和/或响应不同种类的事件时，对CPU上运行的多个任务的有效调度变得复杂。

CPU可以轮询队列状态，在出站队列非满时向出站队列添加消息，或者在入站队列非空时，从入站队列取出消息并进行处理。但轮询队列状态造成对CPU处理能力的浪费。CPU可以响应由队列状态产生的中断，识别事件类型并进行处理。但是当队列事件频繁发生时，大量中断处理带来的开销严重增加了CPU负担。

在桌面CPU、服务器CPU中，通过运行操作系统，由操作系统调度在CPU上运行的多个进程和/或线程，用户无须过多干预进程/线程之间的切换，而由操作系统选择恰当的进程/线程进行调度，以充分利用CPU计算能力。然而，在嵌入式多核CPU中，可使用的存储器、CPU处理能力等资源都受限，难以负担进程/线程管理引入的开销。以及一些嵌入式系统对性能，特别是任务处理延迟有严格要求，操作系统对此场景也难以适用。

根据本申请的第一方面，提供了本申请第一方面的第一任务调度方法，其中，任务调度方法包括：通过应用程序编程接口注册第一事件以及执行第一事件所需的第一条件；根据硬件资源状态更新第一条件；在第一条件满足后，调度第一事件的处理函数。

根据本申请第一方面的第一任务调度方法，提供了本申请第一方面的第二任务调度方法，其中，向应用程序编程接口注册第一事件的处理函数。

根据本申请第一方面的第一或第二任务调度方法，提供了本申请第一方面的第三任务调度方法，其中，在第一事件的处理函数中通过应用程序编程接口注册第二事件以及执行第二事件所需的第二条件。

根据本申请第一方面的第一～第三任务调度方法之一，提供了本申请第一方面的第四任务调度方法，其中，第一事件是IO命令处理的一个阶段。

根据本申请第一方面的第四任务调度方法，提供了本申请第一方面的第五任务调度方法，其中，为IO命令提供上下文资源，所述任务调度方法还包括：通过应用程序编程接口注册第一事件时，指定第一事件使用的上下文资源。

根据本申请第一方面的第一～第五任务调度方法之一，提供了本申请第一方面的第六任务调度方法，其中，所述任务调度方法还包括：响应于调用了第一事件的处理函数，取消对第一事件的注册。

根据本申请第一方面的第一～第五任务调度方法之一，提供了本申请第一方面的第七任务调度方法，其中，所述任务调度方法还包括：响应于调用了第一事件的处理函数，更新第一条件。

根据本申请第一方面的第七任务调度方法，提供了本申请第一方面的第八任务调度方法，其中，所述任务调度方法还包括：响应于调用了第一事件的处理函数，根据硬件资源状态更新第一条件。

根据本申请第一方面的第一～第八任务调度方法之一，提供了本申请第一方面的第九任务调度方法，其中，所述第一条件包括要使用的硬件资源是否可用。

根据本申请第一方面的第一～第九任务调度方法之一，提供了本申请第一方面的第十任务调度方法，其中，处理函数表用于记录处理函数以及调用处理函数所需的条件；所述任务调度方法还包括：从处理函数表中选取其条件已满足的处理函数并调用处理函数。

根据本申请第一方面的第十任务调度方法，提供了本申请第一方面的第十一任务调度方法，其中，所述注册第一事件以及执行第一事件所需的第一条件，包括，在处理函数表中，相关联地记录第一条件以及第一事件的处理函数。

根据本申请第一方面的第一～第十一任务调度方法之一，提供了本申请第一方面的第十二任务调度方法，其中，任务调度方法还包括：记录第一事件的处理函数所需使用的上下文资源。

根据本申请第一方面的第十～第十二任务调度方法之一，提供了本申请第一方面的第十三任务调度方法，其中，任务调度方法还包括：响应于取消对第一事件的注册，在处理函数表中相关联地删除第一条件以及第一事件的处理函数。

根据本申请第一方面的第十一任务调度方法，提供了本申请第一方面的第十四任务调度方法，其中，任务调度方法还包括：根据硬件资源状态，更新处理函数表中同硬件资源对应的第一条件。

根据本申请第一方面的第十四任务调度方法，提供了本申请第一方面的第十五任务调度方法，其中，通过访问指示硬件资源状态的寄存器或处理中断，获取硬件资源状态。

根据本申请第一方面的第十～第十五任务调度方法之一，提供了本申请第一方面的第十六任务调度方法，其中，任务调度方法还包括：从处理函数表中选取其条件已满足的第一处理函数，在第一处理函数所需使用的上下文资源可用时，调用所述第一处理函数，并向所述第一处理函数提供其所需使用的上下文资源。

根据本申请第一方面的第十～第十六任务调度方法之一，提供了本申请第一方面的第十七任务调度方法，其中，任务调度方法还包括：根据优先级选取其条件已满足的处理函数。

根据本申请第一方面的第一～第十七任务调度方法之一，提供了本申请第一方面的第十八任务调度方法，其中，硬件资源为队列、存储器控制器和/或时钟。

根据本申请第一方面的第十八任务调度方法，提供了本申请第一方面的第十九任务调度方法，其中，硬件资源为软件模拟的硬件资源。

根据本申请第一方面的第十八或十九任务调度方法，提供了本申请第一方面的第二十任务调度方法，其中，同类的硬件资源有多份。

根据本申请第一方面的第十八～第二十任务调度方法之一，提供了本申请第一方面的第二十一任务调度方法，其中，第一条件是第一队列可用；调度第一事件的处理函数还包括：获取同第一队列相关联的第一上下文，并将第一上下文作为参数提供给第一事件的处理函数。

根据本申请第一方面的第二十一任务调度方法，提供了本申请第一方面的第二十二任务调度方法，其中，第二条件是从第一队列接收了消息，消息中指示了第二处理函数；所述方法还包括，调度第二处理函数。

根据本申请第一方面的第一～第二十二任务调度方法之一，提供了本申请第一方面的第二十三任务调度方法，其中，任务调度方法还包括：在调度的处理函数执行完成后，获取另一其条件已满足的另一处理函数并调用该另一处理函数。

根据本申请第一方面的第一～第二十三任务调度方法之一，提供了本申请第一方面的第二十四任务调度方法，其中，处理函数使用硬件资源，使得硬件资源变为不可用。

根据本申请第一方面的第一～第二十三任务调度方法之一，提供了本申请第一方面的第二十五任务调度方法，其中，处理函数不使用硬件资源，使得硬件资源依然可用。

根据本申请第一方面的第一～第二十三任务调度方法之一，提供了本申请第一方面的第二十六任务调度方法，其中，在调用硬件资源时，将硬件资源的状态设置为不可用。

根据本申请第一方面的第一～第二十六任务调度方法之一，提供了本申请第一方面的第二十七任务调度方法，其中，通过注册应用程序编程接口更改处理函数和/或调用处理函数所需的条件。

根据本申请第一方面的第一～第二十七任务调度方法之一，提供了本申请第一方面的第二十八任务调度方法，其中，所述任务调度方法还包括：通过发送应用程序编程接口指示通过指定的硬件资源发送消息的事件。

根据本申请第一方面的第二十八任务调度方法，提供了本申请第一方面的第二十九任务调度方法，其中，在发送应用程序编程接口中指示事件的上下文。

根据本申请第一方面的第二十八或二十九任务调度方法，提供了本申请第一方面的第三十任务调度方法，其中，在处理函数表中记录在第一队列可用时，调用第二处理函数；在上下文表中记录要发送的消息；以及完成对发送应用程序编程接口的调用。

根据本申请第一方面的第三十任务调度方法，提供了本申请第一方面的第三十一任务调度方法，其中，在第一队列可用时，调度第二处理函数；以及在第二处理函数被调用时，获取上下文表中记录的要发送的消息，并填充到第一队列。

根据本申请第一方面的第三十一任务调度方法，提供了本申请第一方面的第三十二任务调度方法，其中，任务调度方法还包括：响应于调用了第二处理函数，在处理函数表中相关联地删除对第一队列可用时调用第二处理函数的记录；以及在上下文表中删除要发送的消息。

根据本申请第二方面，提供了本申请第二方面的任务调度装置，其中，任务调度装置包括：注册模块，用于通过应用程序编程接口注册第一事件以及执行第一事件所需的第一条件；更新模块，用于根据硬件资源状态更新第一条件；以及调度模块，用于在第一条件满足后，调度第一事件的处理函数。

根据本申请第三方面，提供了本申请第三方面的第一任务处理系统，其中，任务处理系统包括：处理器和硬件资源，处理器耦合到硬件资源；处理器运行存储器中的任务调度层程序与处理任务的程序；当被处理器运行时，处理任务的代码段通过应用程序编程接口向任务调度层程序注册第一事件以及执行第一事件所需的第一条件；任务调度层程序根据硬件资源状态更新第一条件，以及在第一条件满足后，调度第一事件的处理函数。

根据本申请第三方面的第一任务处理系统，提供了根据本申请第三方面的第二任务处理系统，其中，硬件资源包括一个或多个队列、存储器、时钟和/或定时器。

根据本申请第三方面的第一或二任务处理系统，提供了根据本申请第三方面的第三任务处理系统，其中，当被处理器运行时，任务调度层程序还维护硬件资源状态表，硬件资源状态表记录硬件资源状态。

根据本申请第三方面的第一～三任务处理系统，提供了根据本申请第三方面的第四任务处理系统，其中，当被处理器运行时，任务调度层程序还维护处理函数表，处理函数表记录处理函数以及调用处理函数所需的条件。

根据本申请第三方面的第四任务处理系统，提供了根据本申请第三方面的第五任务处理系统，其中，响应于处理任务的代码段通过应用程序编程接口向任务调度层程序注册第一事件以及执行第一事件所需的第一条件，任务调度层程序在处理函数表中，相关联地记录第一条件以及第一事件的处理函数。

根据本申请第三方面的第五任务处理系统，提供了根据本申请第三方面的第六任务处理系统，其中，任务调度层程序访问指示硬件资源状态的寄存器或处理中断，获取硬件资源状态，并更新处理函数表中同硬件资源状态关联的第一条件。

根据本申请第三方面的第一～六任务处理系统，提供了根据本申请第三方面的第七任务处理系统，其中，当被处理器运行时，任务调度层程序还维护上下文表，上下文表用于记录处理函数所需使用的上下文资源。41、根据权利要求40所述的任务处理系统，其特征在于，其中任务调度层程序选取其条件已满足的第一处理函数，在第一处理函数所需使用的上下文资源可用时，调用所述第一处理函数，并向所述第一处理函数提供其所需使用的上下文资源。

根据本申请第四方面，提供了根据本申请第四方面的第一发送消息的方法，其中，发送消息的方法包括：通过应用程序编程接口注册队列的发送消息的处理函数；通过应用程序编程接口指示要发送的消息；响应于队列可用，调用所述处理函数，通过所述队列发送所述消息。

根据本申请第四方面的第一发送消息的方法，提供了根据本申请第四方面的第二发送消息的方法，其中，通过注册应用程序编程接口指示所述队列与发送消息的所述处理函数。

根据本申请第四方面的第二发送消息的方法，提供了根据本申请第四方面的第三发送消息的方法，其中，通过发送应用程序编程接口指示要发送的消息。

根据本申请第四方面的第一发送消息的方法，提供了根据本申请第四方面的第四发送消息的方法，其中，通过发送应用程序编程接口指示所述队列、发送消息的所述处理函数以及要发送的消息。

根据本申请第四方面的第四发送消息的方法，提供了根据本申请第四方面的第五发送消息的方法，其中，用消息本身或者消息的存储地址指示要发送的消息。

根据本申请第四方面的第三～五发送消息的方法之一，提供了根据本申请第四方面的第六发送消息的方法，其中，响应于调用发送应用程序编程接口，检查所使用的所述队列是否可用；若所述队列可用，调用所述处理函数发送所述消息。

根据本申请第四方面的第六发送消息的方法，提供了根据本申请第四方面的第七发送消息的方法，其中，若所述队列不可用，存储所述消息，以及同所述队列相关联地记录所述处理函数；以及完成调用所述发送程序接口的操作。

根据本申请第四方面的第一～七发送消息的方法，提供了根据本申请第四方面的第八发送消息的方法，其中，发送消息的方法还包括：响应于一个或多个队列可用，选择同所述一个或多个多列相关联的一个或多个处理函数之一，以及调用所选择的处理函数。

根据本申请第四方面的第一～八发送消息的方法，提供了根据本申请第四方面的第九发送消息的方法，其中，发送消息的方法还包括：在发送的消息中指示第二处理函数，和/或第二处理函数的调用条件。

根据本申请的第五方面，提供了根据本申请第五方面的第一接收消息的方法，其中，接收消息的方法包括：通过应用程序编程接口注册队列的接收消息的处理函数；响应于队列可用，调用所述处理函数以执行接收消息的过程。

根据本申请的第五方面的第一接收消息的方法，提供了根据本申请第五方面的第二接收消息的方法，其中，响应于队列中存在消息，从队列中获取消息并将获取的消息提供给所述处理函数。

根据本申请的第五方面的第一接收消息的方法，提供了根据本申请第五方面的第三接收消息的方法，其中，所述处理函数从队列中获取消息。

根据本申请的第五方面的第二或三接收消息的方法，提供了根据本申请第五方面的第四接收消息的方法，其中，检查队列中被取出指定数量的消息后是否依然存在消息而决定是否再次调用处理函数。

根据本申请的第五方面的第一接收消息的方法，提供了根据本申请第五方面的第五接收消息的方法，其中，响应于队列中出现消息，调用处理函数，并且由处理函数决定是否从队列中取出消息。

根据本申请的第五方面的第五接收消息的方法，提供了根据本申请第五方面的第六接收消息的方法，其中，若处理函数未从队列中取出消息，基于队列中依然存在待处理消息而再次调用处理函数。

根据本申请的第五方面的第五或六接收消息的方法，提供了根据本申请第五方面的第七接收消息的方法，其中，若处理函数从队列中取出消息，检查队列中被取出消息后是否依然存在消息而决定是否再次调用处理函数。

根据本申请的第五方面的第一～七接收消息的方法之一，提供了根据本申请第五方面的第八接收消息的方法，其中，接收消息的方法还包括记录队列与处理函数的映射关系，在队列上有待接收的消息时，调用对应的处理函数。

根据本申请的第五方面的第一～八接收消息的方法之一，提供了根据本申请第五方面的第九接收消息的方法，其中，接收消息的方法还包括：从接收的消息中获取第二处理函数，调用第二处理函数。

根据本申请的第五方面的第一～八接收消息的方法之一，提供了根据本申请第五方面的第十接收消息的方法，其中，接收消息的方法还包括：从接收的消息中获取第二处理函数与第二处理函数的触发条件，响应于第二处理函数的触发条件满足，调用第二处理函数。

根据本申请的第五方面的第十接收消息的方法，提供了根据本申请第五方面的第十一接收消息的方法，其中，接收消息的方法还包括：记录所述触发条件与第二处理函数的映射关系，在所述触发条件满足时，调度第二处理函数。

根据本申请的第六方面，提供了根据本申请第六方面的第一读数据方法，其中，读数据方法包括：通过应用程序编程接口，注册源地址、目的地址与处理函数；响应于外部存储器操作完成，调用所述处理函数从所述目的地址处访问数据。

根据本申请的第六方面的第一读数据方法，提供了根据本申请第六方面的第二读数据方法，其中，通过读存储器应用程序编程接口指定源地址与目的地址。

根据本申请的第六方面的第一或二读数据方法，提供了根据本申请第六方面的第三读数据方法，其中，通过应用程序编程接口还指定数据的大小。

根据本申请的第六方面的第一～三读数据方法之一，提供了根据本申请第六方面的第四读数据方法，其中，从所述目的地址访问数据的过程包括：向外部存储器发出读存储器的请求，以及从外部存储器接收读取的数据。

根据本申请的第六方面的第四读数据方法，提供了根据本申请第六方面的第五读数据方法，其中，读数据方法还包括：响应于外部存储器可用，调动所注册的处理函数向外部存储器发出读存储器的请求；以及响应于外部存储器操作完成；再次调用所述处理函数从所述目的地址处访问数据。

根据本申请的第六方面的第一～五读数据方法，提供了根据本申请第六方面的第六读数据方法，其中，读数据方法还包括：在调用的所述处理函数中，指示第三处理函数，和/或第三处理函数的调用条件。

根据本申请的第七方面，提供了根据本申请第七方面的第一写数据方法，其中，写数据方法包括：通过应用程序编程接口，注册源地址、目的地址以及处理函数；响应于外部存储器可用，调用所述处理函数以从本地存储器的源地址向外部存储器的目的地址写入数据。

根据本申请的第七方面的第一写数据方法，提供了根据本申请第七方面的第二写数据方法，其中，通过应用程序编程接口还指定写入数据的大小。

根据本申请的第七方面的第一或二写数据方法，提供了根据本申请第七方面的第三写数据方法，其中，向外部存储器的目的地址写入数据包括：向外部存储器发出写存储器的请求，以及从外部存储器接收写入完成的指示。

根据本申请的第七方面的第三写数据方法，提供了根据本申请第七方面的第四写数据方法，其中，写数据方法还包括：响应于外部存储器可用，调动所注册的处理函数向外部存储器发出写存储器的请求；以及响应于从外部存储器接收写入完成的指示；再次调用所述处理函数。

根据本申请的第七方面的第一～四写数据方法，提供了根据本申请第七方面的第五写数据方法，其中，写数据方法还包括：在调用的所述处理函数中，指示第三处理函数，和/或第三处理函数的调用条件。

根据本申请的第七方面的第一～五写数据方法，提供了根据本申请第七方面的第六写数据方法，其中，硬件资源可用包括存储器控制器空闲和访问存储器的队列空闲。

根据本申请的第八方面，提供了根据本申请第八方面的第一使用用户事件的方法，其中，使用用户事件的方法包括：通过应用程序编程接口，注册响应用户事件的处理函数以及触发所述用户事件的触发条件；在满足所述触发条件时，调用所述处理函数。

根据本申请的第八方面的第一使用用户事件的方法，提供了根据本申请第八方面的第二使用用户事件的方法，其中，通过应用程序编程接口为用户事件指定标识符以及响应事件的处理函数。

根据本申请的第八方面的第二使用用户事件的方法，提供了根据本申请第八方面的第三使用用户事件的方法，其中，使用用户事件的方法还包括：记录用户事件标识符与其处理函数的对应关系。

根据本申请的第八方面的第一～三使用用户事件的方法之一，提供了根据本申请第八方面的第四使用用户事件的方法，其中，触发条件包括触发用户事件的时间，和/或触发用户事件的次数。

根据本申请的第八方面的第一～四使用用户事件的方法之一，提供了根据本申请第八方面的第五使用用户事件的方法，其中，调用所述处理函数包括：获取事件标识符，调用同其对应的处理函数。

根据本申请的第九方面，提供了根据本申请第九方面的第一读数据方法，其中，读数据方法包括：通过应用程序编程接口，注册处理从非易失存储器读出的数据的处理函数；从非易失存储器读出了数据或者从非易失存储器读出数据存在错误时，调用所述处理函数。

根据本申请的第九方面的第一读数据方法，提供了根据本申请第九方面的第二读数据方法，其中，通过应用程序编程接口指定源地址与目的地址，其中源地址是非易失存储器地址。

根据本申请的第九方面的第二读数据方法，提供了根据本申请第九方面的第三读数据方法，其中，通过应用程序编程接口指定一段或多段连续或不连续的源地址和/或目的地址。

根据本申请的第九方面的第二或三读数据方法，提供了根据本申请第九方面的第四读数据方法，其中，通过应用程序编程接口还指定读出数据的大小。

根据本申请的第九方面的第一～四读数据方法之一，提供了根据本申请第九方面的第五读数据方法，其中，响应于访问非易失存储器的硬件资源可用，将从源地址读取数据的请求发送给介质接口控制器。

根据本申请的第九方面的第五读数据方法，提供了根据本申请第九方面的第六读数据方法，其中，在接口控制器提供给了从非易失存储器读取的数据，调用所述处理函数。

根据本申请的第九方面的第一～六读数据方法之一，提供了根据本申请第九方面的第七读数据方法，其中，读数据方法还包括：处理函数在读出数据存在错误时执行数据恢复或错误处理。

根据本申请的第十方面，提供了根据本申请第十方面的第一写数据方法，其中，写数据方法包括：通过应用程序编程接口，注册处理向外部非易失存储器写入数据的处理函数；向外部非易失存储器写数据完成或者写数据失败时，调用所述处理函数。

根据本申请的第十方面的第一写数据方法，提供了根据本申请第十方面的第二写数据方法，其中，通过应用程序编程接口指定源地址与目的地址,其中目的地址是非易失存储器地址。

根据本申请的第十方面的第二写数据方法，提供了根据本申请第十方面的第三写数据方法，其中，通过应用程序编程接口指定一段或多段连续或不连续的源地址和/或目的地址。

根据本申请的第十方面的第二或三写数据方法，提供了根据本申请第十方面的第四写数据方法，其中，通过应用程序编程接口还指定写入数据的大小。

根据本申请的第十方面的第二～四写数据方法之一，提供了根据本申请第十方面的第五写数据方法，其中，响应于访问外部非易失存储器的硬件资源可用，获取源地址与目的地址，向介质接口控制器发送向外部非易失存储器写入数据的请求。

根据本申请的第十方面的第五写数据方法，提供了根据本申请第十方面的第六写数据方法，其中，向介质接口控制器向外部非易失存储器写入数据完成后，调用所述处理函数。

根据本申请的第十方面的第一～六写数据方法之一，提供了根据本申请第十方面的第七写数据方法，其中，在介质接口控制器指示向外部非易失存储器写入数据出现错误时调用所述处理函数执行错误处理。

根据本申请的第十一方面，提供了根据本申请第十一方面的消息发送装置，其中，消息发送装置包括注册模块，用于通过应用程序编程接口注册队列的发送消息的处理函数；指示模块，用于通过应用程序编程接口指示要发送的消息；以及调用模块，用于响应于队列可用，调用所述处理函数，通过所述队列发送所述消息。

根据本申请的第十二方面，提供了根据本申请第十二方面的消息接收装置，其中，消息接收装置包括注册模块，用于通过应用程序编程接口注册队列的接收消息的处理函数；以及调用模块，用于响应于队列可用，调用所述处理函数以执行接收消息的过程。

根据本申请的第十三方面，提供了根据本申请第十三方面的数据读取装置，其中，数据读取装置包括注册模块，用于通过应用程序编程接口，注册源地址、目的地址与处理函数；以及调用模块，用于响应于外部存储器操作完成，调用所述处理函数从所述目的地址处访问数据。

根据本申请的第十四方面，提供了根据本申请第十四方面的数据写入装置，其中，数据写入装置包括注册模块，用于通过应用程序编程接口，注册源地址、目的地址以及处理函数；以及调用模块，用于响应于外部存储器可用，调用所述处理函数以从本地存储器的源地址向外部存储器的目的地址写入数据。

根据本申请的第十五方面，提供了根据本申请第十五方面的使用用户事件的装置，其中，使用用户事件的装置包括注册模块，用于通过应用程序编程接口，注册响应用户事件的处理函数以及触发所述用户事件的触发条件；以及调用模块，用于在满足所述触发条件时，调用所述处理函数。

根据本申请的第十六方面，提供了根据本申请第十六方面的数据读取装置，其中，数据读取装置包括注册模块，用于通过应用程序编程接口，注册处理从非易失存储器读出的数据的处理函数；以及调用模块，用于从非易失存储器读出了数据或者从非易失存储器读出数据存在错误时，调用所述处理函数。

根据本申请的第十七方面，提供了根据本申请第十七方面的数据写入装置，其中，数据写入装置包括注册模块，用于通过应用程序编程接口，注册处理向外部非易失存储器写入数据的处理函数；以及调用模块，用于向外部非易失存储器写数据完成或者写数据失败时，调用所述处理函数。

根据本申请的第十八方面，提供了根据本申请第十八方面的第一任务处理方法，其中，任务处理方法包括：注册第一类用于接收消息的处理函数，第一类用于接收消息的处理函数用于接收第一消息以发起对第一任务的处理；响应于接收第一消息，注册第一类用于发送消息的处理函数指示发送第二消息以继续对所述第一任务的处理；以及注册第二类用于接收消息的处理函数，第二类用于接收消息的处理函数用于接收第三消息以结束对所述第一任务的处理。

根据本申请的第十八方面的第一任务处理方法，提供了根据本申请第十八方面的第二任务处理方法，其中，第一消息为指示IO命令的消息，第一类用于接收消息的处理函数接收指示IO命令的消息，作为IO命令处理过程的开始。

根据本申请的第十八方面的第一或二任务处理方法，提供了根据本申请第十八方面的第三任务处理方法，其中，从入站队列中获取第一消息，并传递给第一类用于接收消息的处理函数。

根据本申请的第十八方面的第一或二任务处理方法，提供了根据本申请第十八方面的第四任务处理方法，其中，被调用的第一类用于接收消息的处理函数从入站队列获取消息。

根据本申请的第十八方面的第四任务处理方法，提供了根据本申请第十八方面的第五任务处理方法，其中，仅当入站队列中出现消息时，才调用第一类用于接收消息的处理函数。

根据本申请的第十八方面的第二～五任务处理方法之一，提供了根据本申请第十八方面的第六任务处理方法，其中，任务处理方法还包括：响应于接收第一消息，为IO命令分配资源。

根据本申请的第十八方面的第六任务处理方法之一，提供了根据本申请第十八方面的第七任务处理方法，其中，为IO命令分配资源包括标识IO命令和/或记录IO命令处理状态。

根据本申请的第十八方面的第二～七任务处理方法之一，提供了根据本申请第十八方面的第八任务处理方法，其中，第二消息为指示对存储设备的非易失存储器进行读/写操作的消息。

根据本申请的第十八方面的第一～八任务处理方法之一，提供了根据本申请第十八方面的第九任务处理方法，其中，在第二消息中指示第三类用于接收消息的处理函数。

根据本申请的第十八方面的第九任务处理方法之一，提供了根据本申请第十八方面的第十任务处理方法，其中，在第二消息中添加第三类用于接收消息的处理函数的指针。

根据本申请的第十八方面的第二～十任务处理方法之一，提供了根据本申请第十八方面的第十一任务处理方法，其中，第三消息为指示读/写非易失存储器的结果的消息。

根据本申请的第十八方面的第九～十一任务处理方法之一，提供了根据本申请第十八方面的第十二任务处理方法，其中，任务处理方法还包括：第二类用于接收消息的处理函数基于第三消息的指示，调用第三类用于接收消息的处理函数。

根据本申请的第十八方面的第九～十二任务处理方法之一，提供了根据本申请第十八方面的第十三任务处理方法，其中，第三类用于接收消息的处理函数用于对存在错误的数据进行。

根据本申请的第十八方面的第二～十三任务处理方法之一，提供了根据本申请第十八方面的第十四任务处理方法，其中，任务处理方法还包括：响应于接收第三消息，注册第二类用于发送消息的处理函数，第二类用于发送消息的处理函数用于发送指示IO命令处理完成的消息。

根据本申请的第十八方面的第十四任务处理方法，提供了根据本申请第十八方面的第十五任务处理方法，其中，响应于IO命令处理完成，释放为IO命令分配的资源。

根据本申请的第十八方面的第十四或十五任务处理方法，提供了根据本申请第十八方面的第十六任务处理方法，其中，任务处理方法处理函数，所述另一第一类用于接收消息的处理函数用于接收应答消息，所述应答消息用于确认对指示IO命令处理完成的消息的接收。

根据本申请的第十九方面，提供了根据本申请第十九方面的第一任务处理方法，其中，任务处理方法包括：注册第一类用于接收消息的处理函数，第一类用于接收消息的处理函数用于接收第一消息以发起对第一任务的处理；响应于接收第一消息，注册第一类用于发送消息的处理函数指示发送第二消息以继续对所述第一任务的处理；注册第二类用于接收消息的处理函数用于接收第三消息以继续对所述第一任务的处理。

根据本申请的第十九方面的第一任务处理方法，提供了根据本申请第十九方面的第二任务处理方法，其中，任务处理方法还包括：响应于接收第三消息，注册第二类用于发送消息的处理函数指示发送第四消息以继续对所述第一任务的处理。

根据本申请的第十九方面的第一任务处理方法，提供了根据本申请第十九方面的第三任务处理方法，其中，任务处理方法还包括：注册第二类用于发送消息的处理函数指示发送第四消息以结束对所述第一任务的处理。

根据本申请的第十九方面的第一～三任务处理方法之一，提供了根据本申请第十九方面的第四任务处理方法，其中，任务处理方法还包括：在所述第二消息中指示第三类用于接收消息的处理函数。

根据本申请的第十九方面的第四任务处理方法，提供了根据本申请第十九方面的第五任务处理方法，其中，任务处理方法还包括：响应于接收第三消息，从第三消息中提取对第三类用于接收消息的处理函数的指示，并通过所述第三类用于接收消息的处理函数继续对所述第一任务的处理。

根据本申请的第十九方面的第一～五任务处理方法之一，提供了根据本申请第十九方面的第六任务处理方法，其中，任务处理方法还包括：响应于接收第一消息，为所述第一任务分配资源。

根据本申请的第十九方面的第一～六任务处理方法之一，提供了根据本申请第十九方面的第七任务处理方法，其中，任务处理方法还包括：响应于接收第三消息，释放为所述第一任务分配的资源。

根据本申请的第十九方面的第一～七任务处理方法之一，提供了根据本申请第十九方面的第八任务处理方法，其中，响应于通过第一类用于接收消息的处理函数接收第一消息，处理任务的起始阶段，为任务分配资源；响应于通过第二类用于接收消息的处理函数接收第三消息，处理任务的第二阶段，并使用所分配的所述资源。

根据本申请的第十九方面的第八任务处理方法，提供了根据本申请第十九方面的第九任务处理方法，其中，响应于接收第一消息，使用所分配的所述资源处理任务的第三阶段，并通过第二类用于发送消息的处理函数指示发送第四消息。

根据本申请的第十九方面的第八任务处理方法，提供了根据本申请第十九方面的第十任务处理方法，其中，任务处理方法还包括：响应于接收第三消息，使用所分配的所述资源处理任务的第四阶段，并通过第二类用于发送消息的处理函数指示发送第四消息。

根据本申请的第十九方面的第八任务处理方法，提供了根据本申请第十九方面的第十一任务处理方法，其中，任务处理方法还包括：向所述第二消息添加指示第三类用于接收消息的处理函数。

根据本申请的第十九方面的第十一任务处理方法，提供了根据本申请第十九方面的第十二任务处理方法，其中，任务处理方法还包括：响应于接收第三消息，从第三消息中提取对第三类用于接收消息的处理函数的指示，并通过所述第三类用于接收消息的处理函数在任务的第五阶段中处理第三消息。

根据本申请的第十九方面的第八～十二任务处理方法之一，提供了根据本申请第十九方面的第十三任务处理方法，其中，任务处理方法还包括：响应于通过第二类用于接收消息的处理函数接收第三消息，释放为任务分配的所述资源。

根据本申请的第二十方面，提供了根据本申请第二十方面的第一任务处理方法，其中，任务处理方法包括：响应于第一队列中出现待处理的第一消息，调用注册给第一队列的第一类用于接收消息的处理函数；响应于第二队列中出现待处理的第二消息，调用注册给第二队列的第二类用于接收消息的处理函数；响应于第三队列可用，调用注册给第三队列的第一类用于发送消息的处理函数。

根据本申请的第二十方面的第一任务处理方法，提供了根据本申请第二十方面的第二任务处理方法，其中，任务处理方法还包括：响应于第四队列可用，调用注册给第四队列的第二类用于发送消息的处理函数。

根据本申请的第二十方面的第一或二任务处理方法，提供了根据本申请第二十方面的第三任务处理方法，其中，响应于第二队列中出现待处理的第二消息，还调用第三类用于接收消息的处理函数。

根据本申请的第二十方面的第一或二任务处理方法，提供了根据本申请第二十方面的第四任务处理方法，其中，响应于第二消息对第三类用于接收消息的处理函数的指示，还调用第三类用于接收消息的处理函数。

根据本申请的第二十方面的第一～四任务处理方法之一，提供了根据本申请第二十方面的第五任务处理方法，其中，任务处理方法还包括：响应于注册第一类用于接收消息的处理函数，将第一队列与第一类用于接收消息的处理函数相关联地记录；响应于注册第二类用于接收消息的处理函数，将第二队列与第二类用于接收消息的处理函数相关联地记录。

根据本申请的第二十方面的第五任务处理方法，提供了根据本申请第二十方面的第六任务处理方法，其中，任务处理方法还包括：响应于通过第一类用于发送消息的处理函数指示发送第三消息，将第三队列与第三类用于接收消息的处理函数相关联地记录。

根据本申请的第二十一方面，提供了根据本申请第二十一方面的任务处理系统，其中，任务处理系统包括：第一注册模块，用于注册第一类用于接收消息的处理函数，第一类用于接收消息的处理函数用于接收第一消息以发起对第一任务的处理；第二注册模块，用于响应于接收第一消息，注册第一类用于发送消息的处理函数指示发送第二消息以继续对所述第一任务的处理；以及第三注册模块，用于注册第二类用于接收消息的处理函数，第二类用于接收消息的处理函数用于接收第三消息以结束对所述第一任务的处理。

根据本申请的第二十二方面，提供了根据本申请第二十二方面的任务处理系统，其中，任务处理系统包括：第一注册模块，用于注册第一类用于接收消息的处理函数，第一类用于接收消息的处理函数用于接收第一消息以发起对第一任务的处理；第二注册模块，用于响应于接收第一消息，注册第一类用于发送消息的处理函数指示发送第二消息以继续对所述第一任务的处理；以及第三注册模块，用于注册第二类用于接收消息的处理函数，第二类用于接收消息的处理函数用于接收第三消息以继续对所述第一任务的处理。

根据本申请的第二十三方面，提供了根据本申请第二十三方面的任务处理系统，其中，任务处理系统包括第一调用模块，用于响应于第一队列中出现待处理的第一消息，调用注册给第一队列的第一类用于接收消息的处理函数；第二调用模块，用于响应于第二队列中出现待处理的第二消息，调用注册给第二队列的第二类用于接收消息的处理函数；以及第三调用模块，用于响应于第三队列可用，调用注册给第三队列的第一类用于发送消息的处理函数。

根据本申请的第二十四方面，提供了根据本申请第二十四方面的第一任务处理系统，其中，任务处理系统包括CPU以及计算机可读存储介质中存储的任务调度层程序与用于处理任务的程序；当所述任务调度层程序被CPU执行时，响应于第一队列中出现待处理的第一消息，调用注册给第一队列的第一类用于接收消息的处理函数；响应于第二队列中出现待处理的第二消息，调用注册给第二队列的第二类用于接收消息的处理函数；以及响应于第三队列可用，调用注册给第三队列的第一类用于发送消息的处理函数；

当所述用于处理任务的程序被CPU执行时，注册第一类用于接收消息的处理函数，第一类用于接收消息的处理函数用于接收第一消息以发起对第一任务的处理；响应于接收第一消息，注册第一类用于发送消息的处理函数指示发送第二消息以继续对所述第一任务的处理；以及注册第二类用于接收消息的处理函数，第二类用于接收消息的处理函数用于接收第二消息以结束对所述第一任务的处理。

根据本申请的第二十四方面的第一任务处理系统，提供了根据本申请第二十四方面的第二任务处理系统，其中，任务处理系统还包括：当被处理器运行时，任务调度层程序还维护处理函数表，处理函数表记录处理函数以及调用处理函数所需的条件。

根据本申请的第二十四方面的第二任务处理系统，提供了根据本申请第二十四方面的第三任务处理系统，其中，任务调度层程序访问指示硬件资源状态的寄存器或处理中断，获取硬件资源状态，并更新处理函数表中同硬件资源状态关联的条件。

根据本申请的第二十四方面的第一～三任务处理系统之一，提供了根据本申请第二十四方面的第四任务处理系统，其中，任务处理系统还包括：当被处理器运行时，任务调度层程序还维护上下文表，上下文表用于记录处理函数所需使用的上下文资源。

根据本申请的第二十四方面的第四任务处理系统，提供了根据本申请第二十四方面的第五任务处理系统，其中，任务处理系统还包括：任务调度层程序选取其条件已满足的第一处理函数，在第一处理函数所需使用的上下文资源可用时，调用所述第一处理函数，并向所述第一处理函数提供其所需使用的上下文资源。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为嵌入式多核CPU系统的框图；

图2A为根据本申请实施例的任务处理系统架构图；

图2B为根据本申请实施例的对处理任务的代码段调度执行的示意图；

图3为根据本申请实施例的任务调度层程序进行任务调度的示意图；

图4为根据本申请实施例的发送消息的流程图；

图5为根据本申请实施例的接收消息的流程图；

图6为根据本申请实施例的从外部存储器读数据的流程图；

图7为根据本申请实施例的向外部存储器写数据的流程图；

图8为根据本申请实施例的使用用户事件的流程图；

图9为根据本申请实施例的从外部非易失存储器读数据的流程图；

图10为根据本申请实施例的向外部非易失存储器写数据的流程图；

图11为根据本申请实施例的处理访问存储设备的IO命令的流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

图2A为根据本申请实施例的任务处理系统架构图。

如图2A所示，任务处理系统包括一个或多个CPU和硬件资源(例如，队列)，CPU耦合到多个队列(入站队列0、入站队列1、出站队列0、出站队列1)，用于同外部设备交换消息。CPU运行存储器中的任务调度层程序与处理任务的程序，例如处理任务的代码段。

CPU上可同时处理多个任务，在图2A所示的例子中，CPU上包括处理任务0的代码段(用“任务0”指示)、处理任务1的代码段(用“任务1”指示)、处理任务2的代码段(用“任务2”指示)、处理任务3的代码段(用“任务3”指示)和处理任务4的代码段(用“任务4”指示)。多个任务按一定顺序处理，协同实现任务处理系统的功能(例如，处理访问存储设备的IO命令)。在每个任务中可以指定其后续任务，或者响应于不同事件的不同后续任务。例如，任务0的后继任务之一是任务2，任务1的后继任务之一是任务0，而任务4的后继任务是任务3。作为举例，每个任务均实现IO命令处理的一个阶段。而在任务处理系统中，可同时处理多个IO命令。相应地，为每个IO命令提供上下文资源(Context)，处理任务的代码段可使用上下文资源来区分对不同IO命令的处理。

当被CPU运行时，任务调度层程序为处理任务的代码段提供API(应用程序编程接口，Application Programming Interface)。处理任务的代码段通过调用API告知任务调度层程序其所要操作的硬件(例如，队列)，由任务调度层程序检查硬件状态，并在硬件资源可用时，操作硬件完成处理任务的代码段通过API所请求的操作。可选地，处理任务的代码段通过调用API还注册用于处理事件的其他代码段，例如，向出站队列1填充消息，又从入站队列1接收到响应消息后，由处理任务2的代码段来处理。任务调度层程序响应于入站队列1上出现消息，调用处理任务2的代码段。

在根据本申请的实施例中，任务调度层程序通过API为处理任务的代码段提供运行环境，其具有以下优点：

(1)任务调度层程序提供的API是异步的，处理任务的代码段调用API后，所调用的API立刻返回，不会阻塞处理任务的代码段的执行；

(2)任务调度层程序处理硬件操作，向处理任务的代码段屏蔽硬件操作细节与差异性，使得处理任务的代码段无须关注硬件资源可用性和/或硬件处理的延迟；

(3)任务调度层程序根据硬件资源的状态调度适当的代码段，安排各个代码段的执行顺序，以平衡任务处理的延迟与CPU执行效率。

图2B为根据本申请实施例的对处理任务的代码段调度执行的示意图。图2B中，从左向右的方向是时间流逝的方向。实线箭头指示了任务处理的时间顺序，虚线箭头指示了任务处理的逻辑顺序。

对于单一CPU，任一时刻仅能处理一段代码。示例性地，如图2B所示，对于待处理的多个代码段，先执行处理任务0的代码段、接下来执行处理任务1的代码段、接下来执行处理任务4的代码段、接下来执行处理任务2的代码段、接下来执行处理任务0的代码段以及接下来执行处理任务3的代码段。而在各个处理任务的代码段中指示了任务处理的逻辑顺序，例如，该逻辑顺序包括任务2要在任务0之后处理、任务0在任务1之后处理、任务3在任务4之后处理等。

通过使用任务调度层程序，向任务调度层程序提供的应用程序编程接口注册进行后续处理的代码段，使得在处理任务的代码段中仅需依照任务的逻辑顺序指定其后继代码段，由任务调度层程序在满足逻辑顺序的要求下，在CPU上调度处理任务的代码段。

在根据本申请的实施例中，处理任务的代码段无须检查硬件资源可用性，无须维护多个处理任务的代码段之间的顺序，从而提升了CPU利用率，也降低了处理任务的代码段的复杂度。

图3是根据本申请实施例的任务调度层程序进行任务调度地示意图。

CPU可用的硬件资源包括多个队列，例如，入站队列与出站队列(参看图1)。硬件资源还包括存储器、定时器等。为协助处理任务的代码段发送消息，任务调度层程序提供注册(register)API、发送(SendMessage)API等API。

在一个例子中，如图3所示，当被CPU运行时，任务调度层程序维护硬件资源状态表，使用硬件资源状态表记录各个硬件资源的状态。例如，在硬件资源状态表中，记录每个队列是否可用。对于入站队列，队列可用意味着入站队列中出现待处理的消息。对于出站队列，队列可用意味着可向出站队列添加消息以发送给队列的接收方。对于定时器，定时器可用意味着定时器到时或定时器未在计时。对于存储器，存储器可用意味着存储器控制器空闲，向存储器完成了数据写入操作或从存储器读出了数据。

如图3所示，当被CPU运行时，任务调度层程序还维护处理函数表，处理函数表记录已注册的同各个硬件资源对应的处理函数。响应于硬件资源可用，调用从处理函数表获取同可用的硬件资源对应的处理函数。

可选地，将硬件资源状态表与处理函数表集成在单一表中。以硬件资源作为表条目的索引，在表条目中记录硬件资源的状态以及处理函数。依然可选地，在该单一表中仅记录可用的硬件资源，响应于硬件资源可用，在单一表中添加对应于可用硬件资源的条目，以及响应于硬件资源不可用，从单一表中删除对应于不可用资源的条目，从而可省略对硬件资源的状态的记录。

在再一个例子中，如图3所示，当被CPU运行时，任务调度层程序还维护上下文表，上下文表用于记录被缓存的上下文(mContext)。

可选地，在处理函数表中，记录同要处理的各个消息对应的处理函数，以及在上下文表中记录同各个消息对应的被缓存的上下文(mContext)。

如图3所示，在CPU初始化阶段，作为举例，处理任务的代码段通过注册(Register)API向任务调度层程序为一个或多个队列注册发送消息的处理函数(例如，被注册给出站队列的处理函数messageOutboundCallback或被注册给入站队列的处理函数messageInboundCallback)(301)。任务调度层程序，作为响应，将队列及其关联的处理函数记录在处理函数表中。

作为又一个例子，处理任务的代码段通过注册API(例如，Register(qID,messageInboundCallback))指定入站队列(qID)与操作硬件(由qID所指示的入站队列)以接收消息的处理函数(messageInboundCallback)(301)。任务调度层程序，作为响应，将由qID指示的队列及其关联的处理函数(messageInboundCallback)记录在处理函数表中。

在步骤302，处理任务的代码段通过发送(SendMessage)API指示要通过由qID所指示的队列发送消息(mContext)。任务调度层程序，作为响应，将由qID指示的队列及其关联的上下文记录在上下文表中。

注册与发送API都是异步的，被调度后不会阻塞处理任务的代码段。注册与发送API可被多次调用，以注册多个处理函数，或发送多个消息。

响应于入站队列中存在待处理消息，任务调度层程序调用操作硬件以接收消息的处理函数(messageInboundCallback)(303)。

响应于出站队列中存在待处理消息，任务调度层程序调用执行操作硬件以发送消息的处理函数(messageOutboundCallback)(304)。

在图3中，作为举例，步骤301与步骤304相关。通过步骤301，将处理函数(messageInboundCallback)与由qID指示的入站队列注册给任务调度层程序；而在由qID指示的入站队列有待处理消息时(步骤304)，任务调度层程序调用同由qID指示的入站队列相关联地注册的处理函数(messageInboundCallback)。

步骤302中，没有指定同由qID指示的出站队列相关联地注册的处理函数。需要通过其他对注册API的调用，以使任务调度层程序在处理函数表中记录同由qID指示的出站队列相关联地注册的处理函数。并由任务调度层在由qID指示的出站队列可用时，通过处理函数表获得相关联的处理函数，以及通过上下文表获得要在由qID指示的出站队列上发送的消息。并调度处理函数来发送消息。

任务调度层程序循环处理步骤310、步骤320与步骤330。

在步骤310，任务调度层程序，获取可用的硬件资源。示例性地，通过访问硬件资源状态表，获取可用的硬件资源(例如，队列)。在一个例子中，当队列可用时，硬件设置对应的状态寄存器指示队列可用，将状态寄存器作为硬件资源状态表的表项。在另一个例子中，当队列可用时产生中断，在中断处理例程中依据可用的队列设置硬件资源状态表的表项。

可选地，若硬件资源状态表指示没有可用的硬件资源，忽略对步骤320与步骤330的执行，从而降低对CPU的利用率。依然可选地，响应于硬件资源状态表指示没有可用的硬件资源，任务调度层程序使自身暂时休眠，或者使CPU休眠，以降低功耗。以及响应于有可用的硬件资源，还恢复对任务调度层程序的执行和/或唤醒CPU。

接下来，在步骤320中，任务调度层程序获取同可用的硬件资源相关联的处理函数。并在步骤330中，调用处理函数。作为一个例子，响应于在步骤310获知入站队列0可用，在步骤320访问处理函数表，以获取同入站队列0相关联的处理函数，并调用该处理函数。可选地，还将可用队列的信息作为参数提供给处理函数。

依然可选地，同队列相关联的处理函数还需要上下文。示例性地，可通过访问上下文表获取同队列相关联的上下文(例如，要通过队列发出的消息)，并将获取的上下文也作为参数提供给同队列相关联的处理函数。

在处理函数执行完成，调用处理函数的步骤330执行完成，返回步骤310，并再次获取可用的硬件资源并基于可用的硬件资源进行处理。

作为又一个例子，响应于出站队列0可用，在步骤320获取同出站队列0关联的处理函数。可选地，若处理函数表中不存在同出站队列0关联的处理函数，则步骤320处理完成，并略过对步骤330的处理，而返回步骤310再次获取可用的硬件资源。依然可选地，同同出站队列0关联的处理函数需要上下文，而访问上下文表未得到对应的上下文，则步骤320处理完成，并略过对步骤330的处理，而返回步骤310再次获取可用的硬件资源。

在一个例子中，处理函数使用可用的硬件资源，并使得可用的硬件资源变为不可用。在又一个例子中，处理函数不使用硬件资源，进而在处理函数执行完成后，导致该处理函数被调用的可用的硬件资源依然可用。在另一个例子中，任务调度层程序使用可用的硬件资源并提供给处理函数，使得无论处理函数是否使用硬件资源，可用的硬件资源都将变为不可用。在依然又一个例子中，可用的硬件资源有多份，任务调度层程序或处理函数使用可用的硬件资源的一份。

处理函数属于处理任务的代码段。在处理函数中可通过注册API向任务调度层程序更改注册到一个或多个队列的处理函数，或者通过发送API向任务调度层程序指示有消息要通过指定的出站队列(由qID指示的出站队列)发出。在发送API中还指示要发送消息的上下文，可选地，在发送API中还指示处理函数。作为响应，任务调度层程序将出站队列及其关联的要发送消息的上下文记录在上下文表中，将出站队列及其关联的处理函数记录在处理函数表中。

可选地，硬件资源也可以是除队列外的其他类型的消息传递装置。例如，消息传递装置可包括用于外发消息的出站消息传递装置以及用于接收消息的入站消息传递装置。消息传递装置可包括多个槽，各个槽可彼此独立的传递消息，以及各个槽之间传递的消息没有顺序约束。对槽的分配由任务调度层处理。处理任务的代码段可仅指示发送消息的消息传递装置。

在一个例子中，任务调度层程序在指定的消息传递装置上有可用的槽时，调用处理函数来发送上下文中指示的消息。在另一个例子中，发送API中指示要发送消息的上下文、消息的接收方(而非消息传递装置)以及处理函数，而由任务调度层程序分配消息传递装置，并将分配的消息传递装置与处理函数记录在处理函数表中。

根据图3的实施例，任务调度层程序与处理任务的代码段都无须等待硬件对消息传递的完成，有助于提高CPU利用率。

实施例二

图4是根据本申请实施例的发送消息的流程图。作为举例，图4所示的发送消息的方法用来将消息发送给其他CPU。

为协助处理任务的代码段发送消息，任务调度层程序提供注册(register)API、发送(SendMessage)API等API。通过注册API向任务调度层程序注册事件的处理函数(例如，操作硬件以发送消息的处理函数)，当出现指定的事件(例如硬件资源可用)，任务调度层程序调用所注册的处理函数以执行发送消息的过程。从而即使运行在不同的硬件平台上，通过修改事件的处理函数得以在不改变代码段结构的情况下，适配不同硬件平台的差异。

如图4所示，为发送消息，在步骤410，处理任务的代码段通过注册API(例如，Register(qID,messageOutboundCallback))指定出站队列(qID)与操作硬件以发送消息的处理函数(messageOutboundCallback)。与之对应地，在步骤401，任务调度层程序在处理函数表中记录硬件资源(例如，由qID指示的出站队列)与处理函数(messageOutboundCallback)的映射关系。在步骤420，处理任务的代码段通过发送API(SendMessage(qID,mContext))指示出站队列(qID)上有待发送的消息(mContext)时，任务调度层程序调用出站队列(qID)关联同的处理函数(messageOutboundCallback)。任务调度层程序还决定调用处理函数(messageOutboundCallback)的时机。在步骤403，响应于硬件资源可用(例如，出站队列(qID)非满)，调用注册的处理函数，使得处理函数(messageOutboundCallback)被执行时(430)，出站队列(qID)可被添加消息。

作为举例，在步骤410中，注册API(例如，Register(qID,messageOutboundCallback))并未指定待发送的消息。

在需要发送消息时，在步骤420中，处理任务的代码段通过调用发送API(SendMessage(qID,mContext))向任务调度层程序指示有消息要通过指定的出站队列(由qID指示的出站队列)发出，以及还指示要发送消息的上下文(mContext)(例如，待发送消息本身，或者消息的存储地址与长度)。

任务调度层程序响应于发送API被调用，在上下文表缓存指定的出站队列(qID)与消息上下文(mContext)，并立即返回(402)，从而调用发送API的处理任务的代码段无须等待消息通过硬件被真实地发送，即可处理后续的操作。

步骤410与步骤420无须连续的执行。例如，在初始化阶段，处理任务的代码段执行步骤410，而在需要发送消息时，执行步骤420。但步骤410与步骤420具有关联性(由虚线箭头指示)。在注册API中，指定了例如出站队列(qID)的处理函数，而在发送API中指定了出站队列(qID)上要发送的消息，而任务调度层调度注册API中指定的处理函数来在出站队列(qID)上发送由发送API所指定的消息。

任务调度层程序检查指定的出站队列的状态(也参看图3的步骤310)。在指定的出站队列(qID)的硬件资源可用(例如，出站队列非满)，调用在指定的出站队列上注册的处理函数(messageOutboundCallback)(403、430)。而在处理函数messageOutboundCallback中直接使用可用的硬件资源以操作硬件发送消息(mContext)。

在上面的例子中，发送API(SendMessage(qID,mContext))没有指定处理函数，任务调度层程序基于注册API(Register(qID,messageOutboundCallback))指定的处理函数，在指定队列(qID)可用时调用指定的处理函数(messageOutboundCallback)。

步骤420与步骤430无须连续的执行，但步骤420中指示了要在接下来执行步骤430。在步骤420执行后，任务调度层程序依据硬件资源的状态确定步骤430的执行时机。可选地，在调用发送API时指定处理函数(messageOutboundCallback)，从而无须通过注册API在出站队列与处理函数之间建立固定的映射关系。另外，可由发送API也注册处理函数，从而为每次消息发送建立与处理函数的映射关系，增强消息发送过程的灵活性。可以理解地，虽然上面将处理函数用单一的名字描述，但是可在每次注册处理函数时，指定不同的处理函数。

依然可选地，响应于调用发送API，任务调度层程序检查所使用的硬件资源(例如，由qID所指示)是否可用。若硬件资源可用，可无须缓存上下文而直接调用处理函数。而仅在所使用的硬件资源不可用时，才缓存上下文并立即返回。

图5是根据本申请实施例的接收消息的流程图。

为协助处理任务的代码段接收消息，任务调度层程序提供注册(register)API等API。通过注册API向任务调度层程序注册操作硬件以接收消息的处理函数，当硬件指示入站队列中出现消息时，任务调度层程序会调用所注册的处理函数以执行接收消息的过程。从而即使运行在不同的硬件平台上，通过修改操作硬件以接收消息的处理函数得以在不改变代码段结构的情况下，适配不同硬件平台的差异。

如图5所示，为接收消息，在步骤510，处理任务的代码段通过注册API(例如，Register(qID,messageInboundCallback))指定入站队列(qID)与操作硬件以接收消息的处理函数(messageInboundCallback)。与之对应地，作为响应，在步骤501，任务调度层程序在处理函数表中记录硬件资源(入站队列(qID))与处理函数(messageInboundCallback)的映射关系。任务调度层程序响应于硬件资源(入站队列(qID))可用，在步骤502，调用注册的处理函数(messageInboundCallback)。处理函数(messageInboundCallback)属于处理任务的代码段的部分。在步骤520，处理函数(messageInboundCallback)被执行。

可选地，通过执行处理函数(messageInboundCallback)，直接使用可用的硬件资源，通过操作硬件接收消息。

可选地，通过注册API(Register())向任务调度层程序指示处理函数的多种使用方式。在一个实施方式中，响应于入站队列(qID)中出现消息，任务调度层程序调用处理函数(messageInboundCallback)，并且任务调度层程序假定处理函数(messageInboundCallback)必然会处理入站队列(qID)中出现的(指定数量(例如1个)的)消息。以及任务调度层程序检查入站队列(qID)中被取出指定数量的消息后是否依然存在消息而决定是否再次调用处理函数(messageInboundCallback)。在另一个实施方式中，响应于入站队列(qID)中出现消息，任务调度层程序调用处理函数(messageInboundCallback)，并且由处理函数(messageInboundCallback)决定是否从入站队列(qID)中取出消息。若处理函数(messageInboundCallback)未从入站队列中取出消息，任务调度层程序将基于入站队列(qID)中依然存在待处理消息而再次调用处理函数(messageInboundCallback)；若处理函数(messageInboundCallback)从入站队列(qID)中取走消息，任务调度层程序检查入站队列(qID)中被取出消息后是否依然存在消息而决定是否再次调用处理函数(messageInboundCallback)。

为协助处理任务的代码段访问外部存储器，任务调度层程序提供用于访问外部存储器的API，包括读存储器(readMemory)API、写存储器(writeMemory)API、同步读存储器(readMemorySync)API、同步写存储器(writeMemorySync)API、存储器复制(copyMemory)API等API。

通过用于访问外部存储器的API向任务调度层程序注册事件的处理函数(例如，对从外部存储器读取的数据进行处理的处理函数(memoryCallback))，当出现指定的事件(例如外部存储器操作完成)，任务调度层程序会调用所注册的处理函数以执行后续操作。

图6是根据本申请实施例的从外部存储器读数据的流程图。

如图6所示，在步骤610，处理任务的代码段通过读存储器API(例如，readMemory(src，dest，memoryCallback))指定源地址(src)、目的地址(dest)与处理函数(memoryCallback)，其中处理函数用于响应外部存储器操作完成。

与之对应地，在步骤601，任务调度层程序响应于读存储器API(例如，readMemory(src，dest，memoryCallback))被调用，缓存读存储器操作的上下文(例如，上下文包括源地址、目的地址、数据大小、指定的处理函数等)，并返回，使得处理任务的代码段可继续执行其他操作。

在步骤602，任务调度层程序响应于访问外部存储器的硬件资源可用(例如，存储器控制器空闲，访存队列空闲等)，获取缓存的上下文，从外部存储器读出数据，将读出的数据写入目的地址。接下来，任务调度层程序调用指定的处理函数(memoryCallback)，作为对事件(读存储器完成)的响应。处理函数(memoryCallback)属于处理任务的代码段的部分。与之对应地，在步骤620，处理函数(memoryCallback)被执行。

可选地，读存储器API还指定读取数据的大小。可选地，源地址位于外部存储器中，而目的地址位于例如CPU的本地存储器。

读存储器API是异步的，该API被调用后会立即返回，而不会阻塞CPU的运行。处理任务的代码通过读存储器API还指定处理函数(memoryCallback)，用于在读存储器操作完成后(数据被写入目的地址)执行后续处理。

可选地，从目的地址访问数据的过程分为两个阶段：向外部存储器发出读存储器请求，与从外部存储器接收读取的数据。两个阶段之间可能存在较长的延迟。任务调度层程序在执行了向外部存储器发出读存储器请求阶段后，再次缓存上下文，并在硬件资源可用(外部存储器提供了读取的数据)后，再获取缓存的上下文，将数据写入目的地址，并调用指定的处理函数，以缩短延迟。

可选地，调用读存储器API(例如，readMemory(src，dest)时不指定处理函数。任务调度层程序完成读取存储器操作后也不调用处理函数。

从存储器读取数据是为了使用数据。根据本申请的实施例，任务调度层程序在从存储器读取了数据后，调用处理函数(memoryCallback)对读取的数据进行处理，从而无须处理任务的代码段等待或反复查询是否从存储器读取了数据。消除了异步存储器访问方式所引入的额外开销，降低了处理任务的代码段的编程复杂度。

图7是根据本申请实施例的向外部存储器写数据的流程图。

如图7所示，在步骤710，处理任务的代码段通过写存储器API(例如，writeMemory(src，dest，memoryCallback))指定源地址(src)与目的地址(dest)。目的地址位于外部存储器中，而源地址位于例如CPU的本地存储器。可选地，写存储器API还指定写数据的大小。写存储器API是异步的，该API被调用后会立即返回，而不会阻塞CPU的运行。

任务调度层程序响应于写存储器API(例如，writeMemory(src，dest，memoryCallback))被调用，缓存读存储器操作的上下文(例如，上下文包括源地址、目的地址、数据大小等)，并返回(701)，使得处理任务的代码可继续执行其他操作。

任务调度层程序响应于访问外部存储器的硬件资源可用(例如，存储器控制器空闲，访存队列空闲等)，获取缓存的上下文，向外部存储器写入数据。

可选地，写存储器API还指定处理函数(memoryCallback)。处理函数(memoryCallback)，用于在写存储器操作完成后(数据被写入目的地址)执行后续处理。

响应于向存储器写入了数据，在步骤702，任务调度层程序调用指定的处理函数(memoryCallback)，作为对事件(写存储器完成)的响应。与之对应地，处理函数(memoryCallback)被执行。作为一个例子，在处理函数(memoryCallback)中向另一处理器发消息以指示该另一处理器可访问被写入存储器的数据。可选地，在消息中携带函数指针，该另一处理器通过调用函数指针所指示的函数，来访问被写入存储器的数据。

可选地，向外部存储器的目的地址写入数据的过程分为两个阶段：向外部存储器发出写存储器请求，与从外部存储器接收写入完成的指示。两个阶段之间可能存在较长的延迟。任务调度层程序在执行了向外部存储器发出写存储器请求阶段后，再次缓存上下文，并在硬件资源可用(外部存储器指示写存储器完成)后，再获取缓存的上下文，并调用指定的处理函数，以缩短延迟。

可选地，调用写存储器API(例如，writeMemory(src，dest))时不指定处理函数。任务调度层程序完成写取存储器操作后也不调用处理函数。

类似地，处理任务的代码段通过存储器复制(Copy(src,dest))API指定源地址(src)与目的地址(dest)，以将源地址的数据复制到目的地址。源地址与目的地址均位于外部存储器中。由任务调度层处理存储器复制操作。

此外，在根据本申请的实施例中，还提供同步读存储器API、同步写存储器API等API。处理任务的代码段调用同步读存储器API或同步写存储器API后，在任务调度层程序完成了存储器访问操作后，才返回处理任务的代码段继续执行。此时，处理任务的代码段已可以使用从存储器获取的数据。

图8是根据本申请实施例的使用用户事件的流程图。

在根据本申请的实施例中，处理任务的代码段可通过应用程序编程接口向任务调度层程序注册响应用户事件的处理函数以及触发用户事件的触发条件。例如，触发条件包括：触发事件的时间，和/或触发事件的次数。任务调度层程序依据所指定的触发条件调用处理函数。任务调度层程序提供注册(register)API，用于注册事件。如图8所示，在步骤810，处理任务的代码通过注册API(例如，Rgister(eventID，userEventCallback))为事件指定标识符(eventID)以及响应事件的处理函数(userEventCallback)。响应作为，在步骤801，任务调度层程序记录事件(例如，记录事件的标识符(eventID))与其处理函数(userEventCallback)的映射关系。

在一个实施方式中，任务调度层程序还提供触发API(例如，TriggerUserEvent(eventID))。在步骤820，处理任务的代码段通过调用任务调度层程序提供的触发API来产生指定事件(由事件标识符(eventID)所指示)。与之对应地，在步骤802，任务调度层程序缓存指定事件的上下文(标识符(EventID)等)，例如，记录由eventID所指示的事件已产生的状态，并返回，使得处理任务的代码得以继续执行。

任务调度任务调度层程序通过缓存的上下文，获取处于已产生状态的事件，进而获取同已产生事件对应的已注册的处理函数(userEventCallback)。在步骤803,，任务调度层程序调用注册的处理函数(userEventCallback)，与之对应地，在步骤830，同用户事件相关联的处理函数(userEventCallback)被执行。

可选地，触发API中还可指定触发事件的条件。在另一个实施方式中，在注册API中明示或暗示触发事件的条件，而无须使用触发API。由任务调度层程序从缓存的上下文中识别触发事件的条件，在条件满足时，调用已注册的处理函数。

图9是根据本申请实施例的从外部非易失存储器(NVM，Non-Volatile Memory)读数据的流程图。

为协助处理任务的代码段访问外部NVM，任务调度层程序提供用于访问NVM的API，包括读NVM(readNVM)、写NVM(writeNVM)、设置NVM(SetNVM)API等。

在步骤910，处理任务的代码段通过读NVM API(例如，readNVM(dest，pba，NVMCallback))指定源地址(pba)与目的地址(dest)，以将NVM上的由源地址所指示的数据读出并存储到由目的地址(dest)所指示的位置。可选地，读NVM API还指定读取数据的大小。目的地址位于外部存储器或CPU的本地存储器中。读NVM API(readNVM(dest，pba，NVMCallback))是异步的，该读NVM API(readNVM(dest，pba，NVMCallback))被调用后会立即返回，而不会阻塞CPU的运行。处理任务的代码通过读NVM API(readNVM(dest，pba，NVMCallback))还指定处理函数(NVMCallback)，用于在读NVM操作完成后(即数据被从NVM读出)执行后续处理。

在步骤901，任务调度层程序响应于读NVM API(readNVM(dest，pba，NVMCallback))被调用，缓存读NVM操作的上下文(例如，上下文包括源地址、目的地址、数据大小、指定的处理函数等)，并返回，使得处理任务的代码段可继续执行其他操作。

任务调度层程序响应于访问NVM的硬件资源可用(例如，介质接口控制器空闲等，在中国专利申请CN201610009789.6、CN201510253428.1、CN201610861793.5、CN201611213755.5、CN201611213754.0中提供了多种介质接口控制器，也可使用现有技术中的访问闪存等NVM的介质接口控制器)，获取缓存的上下文，将从源地址读取数据的请求发送给介质接口控制器。从介质接口控制器接收要读取数据的请求到NVM输出数据有较大的延迟。任务调度层程序在执行了向介质接口控制器发送从NVM读取数据的请求，再次缓存上下文，并在硬件资源可用(介质接口控制器提供了从NVM读取的数据)后(902)，再获取缓存的上下文，并调用指定的处理函数(920)，以缩短延迟。

可选地，处理函数用于将读出的数据通过DMA操作发送给主机，或者在读出数据存在错误时执行数据恢复或错误处理。

可选地，读NVM API可指定一段或多段连续或不连续的源地址和/或目的地址，以从NVM的多个位置获取数据。

图10是根据本申请实施例的向外部非易失存储器(NVM，Non-Volatile Memory)写数据的流程图。

在步骤1010，处理任务的代码段通过写NVM API(例如，WriteNVM(sec，pba，NVMCallback))指定源地址(src)与目的地址(pba)，以将源地址处的数据写入NVM上由目的地址所指示的位置。可选地，写NVM API还指定读取数据的大小。源地址位于外部存储器或CPU的本地存储器中。写NVM API是异步的，该写NVM API被调用后会立即返回，而不会阻塞CPU的运行。处理任务的代码通过写NVM API还指定处理函数(NVMCallback)，用于在写NVM操作完成后(即数据被写入NVM)执行后续处理。

在步骤1001，任务调度层程序响应于写NVM API(例如，WriteNVM(sec，pba，NVMCallback))被调用，缓存写NVM操作的上下文(例如，上下文包括源地址、目的地址、数据大小、指定的处理函数等)，并返回，使得处理任务的代码段可继续执行其他操作。

任务调度层程序响应于访问NVM的硬件资源(例如，介质接口控制器)可用，获取缓存的上下文，向介质接口控制器发送向NVM写入数据的请求。从介质接口控制器接收要写入的数据与写入操作完成有较大的延迟。任务调度层程序在向介质接口控制器发送向NVM写入数据的请求，再次缓存上下文，并在硬件资源可用(介质接口控制器指示向NVM写入数据完成)后(1002)，再次获取缓存的上下文，并调用指定的处理函数(NVMCallback)(1020)，以缩短延迟。

可选地，处理函数在写入操作出错时执行错误处理。

可选地，写NVM API可指定一段或多段连续或不连续的源地址和/或目的地址，以向NVM的多个位置写入数据。

类似地，处理任务的代码段通过任务调度层程序提供的设置NVM(SetNVM)API对指定的NVM进行设置。任务调度层程序还提供异步操作NVM的其他API。

实施例三

在根据本申请的实施例中，多个任务按一定顺序处理，协同实现任务处理系统的功能(例如，处理访问存储设备的IO命令)。为实现功能，需要多次(例如通过出站队列)发送消息以及多次(例如通过入站队列)接收消息。

任务调度层程序提供多种类型的处理函数来处理发送消息与接收消息的操作。通过组合处理函数，实现多种任务处理过程。不同类型的处理函数来适配任务处理系统的功能的不同阶段。

作为举例，为实现处理IO命令的功能，需要将其划分为多个阶段，并为各个阶段提供不同类型的函数。示例性地，如图11所示，将其划分为如下几个阶段：(1)接收IO命令(1115)；(2)依据IO命令访问NVM芯片(1118)；(3)从NVM芯片获取访问结果(1155)；(4)指示IO命令处理完成(1158)；以及可选地(5)接收应答(1185)。

第(1)阶段，接收指示IO命令的消息(1115)，作为IO命令处理过程的开始。第(2)阶段，为IO命令分配资源(例如，标识IO命令、记录IO命令处理状态)，并发出消息，以访问存储设备(1118)。第(3)阶段，接收消息，消息中指示了存储设备访问结果(1155)，以及IO命令所使用的资源(从而将所接收的消息指示的IO命令同步骤(2)中的消息指示的IO命令关联)。第(4)阶段，发出指示IO命令处理完成的消息(1158)。可选地，第(5)阶段，接收应答消息(1185)，应答消息中指示了第(4)阶段的IO命令处理完成的消息已被正确接收。

与之相应地，提供多类用于接收消息的处理函数以及多类用于发送消息的处理函数。示例性地，第一类用于接收消息的处理函数(PortDriver)，所接收的消息中不包括功能的上下文，用于在例如功能的起始阶段接收消息。第二类用于接收消息的处理函数(Generic Driver)，所接收的消息中包括功能的上下文，用于在例如功能的中间阶段接收消息。第三类用于接收消息的处理函数(MiniDriver)，不能单独使用，而是对第二类用于接收消息的处理函数的扩展，并且在所接收的消息中指示第三类用于接收消息的处理函数。第一类用于发出消息的处理函数，用于处理消息发送过程(GenericDriver)。第二类用于发出消息的处理函数(GenericDriver+minidriver)用于处理消息发送过程，并且在消息中指示第三类用于接收消息的处理函数。

当然，也可以有其他类型的用于发送消息或接收消息的处理函数。为实现任务处理系统的功能，组合使用处理函数的一种或多种。

图11是根据本申请实施例的处理访问存储设备的IO命令的流程图。处理任务的代码段与任务调度层程序运行在任务处理系统的CPU之一(记为CPU 0)上。

响应于入站队列11A出现指示IO命令的消息，在步骤1110，任务调度层程序调用第一类用于接收消息的处理函数。第一类用于接收消息的处理函数作为任务之一或任务的部分，通过获取消息来识别IO命令的内容。在一种实施方式中，任务调度层程序从入站队列中获取消息，并传递给第一类用于接收消息的处理函数。在又一种实施方式中，被调用的第一类用于接收消息的处理函数从入站队列中获取消息。任务调度层程序仅当入站队列中出现消息时，才调用第一类用于接收消息的处理函数，从而第一类用于接收消息的处理函数无须查询或等待入站队列可用。

响应于接收了IO命令(1115)，处理任务的代码段为IO命令分配资源，并访问存储设备(1118)。为访问存储设备，向出站队列11B发出消息，以指示任务处理系统的其他CPU或控制器对存储设备的NVM芯片进行读/写操作。可选地，处理任务的代码段调用发送(sendMessage)API，来向出站队列发出消息。在步骤1120，任务调度层程序响应于发送(sendMessage)API被调用，注册第二类用于发送消息的处理函数，第二类用于发送消息的处理函数用于发送指示对NVM芯片进行读/写操作的消息，使得在步骤1130，任务调度层程序依据出站队列状态可调度第二类用于发送消息的处理函数，从而第二类用于发送消息的处理函数被执行时出站队列已经可用，而无须查询或等待出站队列可用。在可选的实施方式中，响应于发送(sendMessage)API被调用，任务调度层程序基于出站队列已经可用，而直接调用第二类用于发送消息的处理函数，而省去注册第二类用于发送消息的处理函数的过程。在第二类用于发送消息的处理函数中，操作出站队列以通过出站队列发出消息，以及可选地，还在消息中指示第三类用于接收消息的处理函数，例如，在消息中添加第三类用于接收消息的处理函数的指针。

任务处理系统的其他CPU或控制器读/写NVM芯片，并将对读/写结果的指示通过入站队列发送给图11中运行处理任务的代码段的CPU(CPU 0)。响应于入站队列11C出现指示读/写NVM芯片的结果的消息，在步骤1140，任务调度层程序调用第二类用于接收消息的处理函数。第二类用于接收消息的处理函数作为任务之一或任务的部分，通过获取消息来识别读/写NVM芯片的结果。可选地，在图11的实施例中，第二类用于接收消息的处理函数或任务调度层程序还基于消息的指示，在步骤1150，调用第三类用于接收消息的处理函数。第三类用于接收消息的处理函数作为任务之一或任务的部分对消息进行进一步处理，例如，对存在错误的数据进行恢复。通过在消息中指示调用第三类用于接收消息的处理函数，使得在通过出站队列发出消息时可对消息指定处理函数，提升了消息处理的灵活性。

可选地，响应于接收了指示读/写NVM芯片的结果的消息(1155)，处理任务的代码段发出指示IO命令处理完成的消息(1158)，向例如主机告知IO命令处理完成。可选地，处理任务的代码段通过调用发送(sendMessage)API，在步骤1160，任务调度层程序响应于发送(sendMessage)API被调用，注册第一类用于发送消息的处理函数，第一类用于发送消息的处理函数用于发送指示IO命令处理完成的消息，使得在步骤1170，任务调度层程序依据出站队列状态可调度第一类用于发送消息的处理函数。在第一类用于发送消息的处理函数中，操作出站队列以通过出站队列11D发出消息。在发出的消息中不包括对第三类用于接收消息的处理函数的指示。以及由于IO命令处理完成，释放为IO命令分配的资源。

可选地，响应于指示IO命令处理完成的消息，IO命令发出方还会给出应答消息，以确认对指示IO命令处理完成的消息的接收。应答消息被填入入站队列。响应于入站队列11E出现应答消息，在步骤1180，任务调度层调用另一第一类用于接收消息的处理函数获取应答消息(1185)。

可选地，任务处理系统的功能可包括更多或更少的阶段。各个阶段通过向其他CPU/控制器发出消息或从其他CPU/控制器接收消息来处理任务。对功能的实现由接收消息开始，在实现功能的中间一个或多个阶段，发送消息与接收消息成对出现，在发送消息时可注册接收消息时使用的第二类用于接收消息的处理函数，以及在发出的消息中可添加对接收消息时使用的第三类用于接收消息的处理函数的指示，从而在接收消息时，调用第二类用于接收消息的处理函数，以及可选地第三类用于接收消息的处理函数。可选地，在初始化时为一个或多个入站队列注册第二类用于接收消息的处理函数，以及在发出的消息中添加对接收消息时使用的第三类用于接收消息的处理函数的指示。

任务调度层程序、多种用于接收消息的处理函数与多种用于发送消息的处理函数为实现任务处理系统的功能提供了运行环境或框架。实现功能的多个处理任务的代码段通过调用发送(sendMessage)API发送消息，以及向接收队列注册用于接收消息的处理函数。

调用发送(sendMessage)API、用于发送消息的处理函数与用于接收消息的处理函数都不会阻塞处理任务的代码段的执行。发送(sendMessage)API是异步的，用于注册用于发送消息的处理函数。而任务调度层程序根据出站队列/入站队列的状态，仅在资源可用时才调度用于发送消息的处理函数或用于接收消息的处理函数，从而不会阻塞处理任务的代码段的执行。

发送消息的处理函数/用于接收消息的处理函数，向处理任务的代码段屏蔽硬件(例如出站队列/入站队列)操作细节与差异性；使得处理任务的代码段无须关注硬件资源可用性和/或硬件处理的延迟。从而简化了任务处理系统的开发，使的任务处理系统易于迁移到其他硬件平台。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims

1.一种任务处理方法，其特征在于，包括：

注册第一类用于接收消息的处理函数，第一类用于接收消息的处理函数用于接收第一消息以发起对第一任务的处理；

响应于接收第一消息，注册第一类用于发送消息的处理函数指示发送第二消息以继续对所述第一任务的处理；以及

注册第二类用于接收消息的处理函数，第二类用于接收消息的处理函数用于接收第三消息以结束对所述第一任务的处理。

2.根据权利要求1所述的任务处理方法，其特征在于，其中，第一消息为指示IO命令的消息，第一类用于接收消息的处理函数接收指示IO命令的消息，作为IO命令处理过程的开始。

3.根据权利要求1或2所述的任务处理方法，其特征在于，在第二消息中指示第三类用于接收消息的处理函数。

4.根据权利要求3所述的任务处理方法，其特征在于，在第二消息中添加第三类用于接收消息的处理函数的指针。

5.根据权利要求3或4所述的任务处理方法，其特征在于，还包括：第二类用于接收消息的处理函数基于第三消息的指示，调用第三类用于接收消息的处理函数。

6.一种任务处理方法，其特征在于，包括：

响应于接收第一消息，注册第一类用于发送消息的处理函数指示发送第二消息以继续对所述第一任务的处理；

注册第二类用于接收消息的处理函数用于接收第三消息以继续对所述第一任务的处理。

7.根据权利要求6所述的任务处理方法，其特征在于，响应于通过第一类用于接收消息的处理函数接收第一消息，处理任务的起始阶段，为任务分配资源；

响应于通过第二类用于接收消息的处理函数接收第三消息，处理任务的第二阶段，并使用所分配的所述资源。

8.一种任务处理方法，其特征在于，包括：

响应于第一队列中出现待处理的第一消息，调用注册给第一队列的第一类用于接收消息的处理函数；

响应于第二队列中出现待处理的第二消息，调用注册给第二队列的第二类用于接收消息的处理函数；

响应于第三队列可用，调用注册给第三队列的第一类用于发送消息的处理函数。

9.根据权利要求8所述的任务处理方法，其特征在于，

响应于第二队列中出现待处理的第二消息，还调用第三类用于接收消息的处理函数。

10.一种任务处理系统，其特征在于，包括：第一注册模块，用于注册第一类用于接收消息的处理函数，第一类用于接收消息的处理函数用于接收第一消息以发起对第一任务的处理；第二注册模块，用于响应于接收第一消息，注册第一类用于发送消息的处理函数指示发送第二消息以继续对所述第一任务的处理；以及第三注册模块，用于注册第二类用于接收消息的处理函数，第二类用于接收消息的处理函数用于接收第三消息以结束对所述第一任务的处理。