实时安卓操作系统中的实时Binder处理避免非实时Binder竞争的方法与流程

本发明涉及通信数据处理技术领域，具体涉及一种实时安卓操作系统中的实时binder处理避免非实时binder竞争的方法。

背景技术：

随着soc（systemonchip）技术的不断发展，嵌入式系统在人们生产，生活的各个方面应用越来越广泛，大到航天航空，小到智能手机、智能手表等，可以说是无处不在。由于工作的特殊性，很多嵌入式设备要求系统对外部事件的响应必须在实现设定的时限范围内完成，使系统具有可预测性，因此就必须使用实时操作系统。

常用的嵌入式实时操作系统包括有硬时vxworks，qnx和ucosii等，软实时则包括有wince等。像vxworks，qnx和ucosii等都是一些功能比较简单的封闭式操作系统。随着现在的系统日趋复杂，越来越需要把一些通用的有完善生态链的分时操作系统，如：linux、windows等改造成实时操作系统，这样既能满足通用需求又能满足特殊需求。由于linux开源的特性，这方面已有一些很好的解决方案，如：rtlinux、rtai、montavista等。

现在使用越来越广泛的谷歌安卓（android）操作系统也是一种通用的有完善生态链的分时操作系统，它基于linux内核。安卓（android）操作系统中最重要的进程间通讯机制就是binder机制。binder机制在安卓（android）操作系统中可以说是无处不在。普通的binder机制用来处理非实时的逻辑，也没有引入优先级的概念。实时安卓操作系统（rtandroid）中可以将binder机制用于处理实时逻辑。但将binder机制用于处理实时逻辑有一个必须要解决的问题，由于binder机制在安卓（android）操作系统中可以说是无处不在，在同一进程中，在处理非实时binder请求时，由于binder驱动中的todo链表加了锁，只有当非实时binder请求处理完后，实时binder才能得到处理，这显然和实时系统的设计原则是不吻合的。具体的说，现有的binder通讯机制是，当用户进程发起binder请求后，先到达binder服务类和接口类，再到达binder核心类，然后到达ipcthreadstate类，最后抵达运行在内核空间的binder驱动。请求的结果按相反的路线返回到用户进程。ipcthreadstate类负责和binder驱动通讯并维护了binder线程池。在安卓现在的设计中，每个用户进程中都只有一个ipcthreadstate类的实例。另外，安卓系统还有一个特殊的binder服务servicemanager，它为binder机制提供名字服务。binder驱动为每个进程维护了binder_proc的数据结构，而binder_proc上也包含等待队列，这样binder线程可在上面睡眠。另外，binder_proc上也维护了fifo队列，来缓存binder驱动在某个进程上所有未处理的工作。另外，binder驱动也维护了锁，来同步同一个进程上并发的binder请求。

在实时安卓操作系统（rtandroid）中，binder机制也被用来处理实时的事件或请求的跨进程传递需求，因为binder机制是一种高效且编程灵活的跨进程通讯机制。从上面分析可以，如果不对安卓原生的binder机制做改进，实时的事件或请求的binder处理没有被区别对待，当系统中的非实时binder请求频繁且繁忙时，实时的事件或请求的binder处理将延迟很多，实时性能将得不到保证。

技术实现要素：

本发明目的在于提供实时安卓操作系统中的实时binder处理避免非实时binder竞争的方法，基于实时安卓操作系统实现，适用于将安卓操作系统改造成实时的安卓操作系统中，也适用于任何使用binder机制的实时操作系统中，来避免实时binder处理时，非实时binder请求的竞争问题。

为了实现上述目的，本发明采用以下技术方案：

实时安卓操作系统中的实时binder处理避免非实时binder竞争的方法，其特征在于，包括以下步骤：

s1：判定binder请求的性质，属于实时binder请求还是普通binder请求，若是实时binder请求则执行步骤s2；

s2:binder驱动向ipcthreadstate类实例请求线程，spawn出硬实时或软实时线程以用于处理实时binder请求;

s3:binder驱动公平对待所有实时binde或将实时binder请求有序的插入队列中。

作为一种优选技术方案，包括分离于普通binder机制的模式和/或内嵌于普通binder的模式；

分离于普通binder机制的模式是指系统中有两个binder驱动和对应的设备文件，分别为原生binder驱动和实时binder驱动；一个用户进程存在两个ipcthreadstate类的实例，分别普通的ipcthreadstate类的实例和实时的ipcthreadstate类的实例，为其运行包括以下步骤：

s1a：上层的binder服务类和接口类，以及binder核心类可以区分出binder请求性质，若是实时binder请求则找到实时的ipcthreadstate类实例，若是普通binder请求则找到普通的ipcthreadstate类实例；

s2a：实时binder请求通过实时的ipcthreadstate类实例将请求发送给实时binder驱动；实时binder驱动请求实时的ipcthreadstate类实例spawn出硬实时或软实时线程以用于处理实时binder请求；

s3a：实时binder驱动公平对待所有实时binder请求或者按优先级把它们有序地插入到对应的一个或多个进程的fifo队列中；

内嵌于普通binder的模式，系统中只存一个binder驱动，每个用户进程也只有一个ipcthreadstate类的实例，binder库中有特定于实时binder请求的接口或接口附加的参数，以区分是实时binder请求还是普通binder请求，其运行包括以下过程：

s1b:由binder库中的特殊接口或接口参数标明binder请求是一个实时binder请求；

s2b:binder驱动向ipcthreadstate类实例请求spawn线程时，通过特定参数或是binder协议中特定的命令，指明需要创建的线程是硬实时或软实时线程，ipcthreadstate类实例将创建相应的线程以在这样线程中处理实时binder请求；

sb3：在每个用户进程对应的binder_proc结构中，为实时binder请求专门维护了实时binder的等待队列rt_wait_queue和实时binder的fifo队列rt_todo_list。

作为一种优选技术方案，当系统同时配置上述两种模式时，软件调用一个特定的接口可选择两种模式中的一种，如果不调用，缺省的认为选择分离于普通binder的模式。

作为一种优选技术方案，当在运行分离于普通binder机制的模式或内嵌于普通binder机制的模式之前还包括以下过程：

读取配置或由用户调用的接口获得用户选用哪种模式，若选用分离于普通binder机制的模式，则分离于普通binder机制的模式运行；若选用内嵌于普通binder机制的模式，则内嵌于普通binder机制的模式运行。

作为一种优选技术方案，在分离于普通binder的模式下，不同的实时binder请求之间的竞争，有两种处理方式，第一种，所有实时binder请求公平对待，第二种，实时binder请求根据优先级排序；两种方式用户可通过特定配置或特定接口选择；在第二种方式中，优先级缺省地设为硬实时或软实时的线程优先级，当某binder请求发起后，到达实时binder驱动，在不打断正在处理的binder请求的前提下，按优先级排序插入到fifo队列的相应位置。

作为一种优选技术方案，在分离于普通binder的模式中，系统中存在一servicemanager或两个servicemanager；

当存在两个servicemanager时，其中一个为原生servicemanager，另一个为专门服务于实时binder的servicemanager，binder库区分出是哪个ipcthreadstate类的实例，就可以访问到相应的servicemanager，从而得到正确的服务；

当只存在一个servicemanager时，实时binder驱动在需要servicemanager的服务时，通过一个设定的特殊接口找到普通binder的ipcthreadstate类的实例，从而访问普通binder驱动来获得服务。

作为一种优选技术方案，实时binder的fifo队列的数据结构中有标志来指明它是否来自实时binder请求。

本发明与现有技术相比，具有以下有益效果：

通过分离于普通binder的模式和内嵌于普通binder的模式中的任意一种(对单次实时binder请求来说)，将普通binder请求竞争实时binder请求的可能性及延时降到最低,保证了实时事件或请求通过binder机制来进行跨进程传递的性能。两种模式下，实时binder请求都可在硬实时或软实时的线程中进行处理，提高了效率。其中分离于普通binder的模式将竞争的可能性降到最低。

附图说明

图1为本发明的流程示意图。

具体实施方式

实施例

实时安卓操作系统中的实时binder处理避免非实时binder竞争的方法包括分离于普通binder的模式和/或内嵌于普通binder的模式，可以通过软件只配置其中一种模式工作，也可配置成两种模式同时存在，软件调用一个特定的接口可选择两种模式中的一种，如果不调用，缺省的选择分离于普通binder的模式。

上述分离于普通binder的模式是指系统中除了安卓原生的binder驱动和对应的设备文件外，还有另一个专门服务实时binder请求的binder驱动和对应的设备文件。对应的设备文件-binder库中的binder服务类和接口类，以及binder核心类基本保持与原生的一致，这样做的目的是为了让实时binder上层应用与安卓原生的设计尽量保持兼容。

在分离于普通binder的模式下，同一个用户进程中有两个ipcthreadstate类的实例，分别为普通ipcthreadstate类的实例和实时ipcthreadstate类的实例。一个实例同普通binder驱动通讯，另一个实例同实时binder驱动通讯。上层的binder服务类和接口类，以及binder核心类可以区分出是普通binder请求，还是实时binder请求，从而找到相应的ipcthreadstate类的实例。两个实例可以位于两个不同binder库中，也可位于同一个binder库中，由增加的特定接口去区分应访问的ipcthreadstate类的实例。

普通ipcthreadstate类的实例维护的线程池中的线程是普通的安卓binder线程，而实时ipcthreadstate类的实例维护的线程池中的线程是硬实时线程或软实时线程，这样可以提高处理实时binder请求的效率。由于实时binder请求都由实时binder驱动服务，实时binder驱动不服务普通binder请求，所以实时binder请求不会被普通binder请求所竞争，竞争只存在于不同的实时binder请求之间，所以这就解决了由于普通binder的竞争而延迟实时binder请求的问题。不同的实时binder请求之间的竞争，有两种处理方式，第一种，所有实时binder请求公平对待，第二种，实时binder请求根据优先级排序。两种方式用户可通过特定配置或特定接口选择。对于第二种方式需要说明的是，优先级缺省地设为硬实时或软实时的线程优先级，但用户也可通过特定接口来修改binder请求的优先级，当某binder请求发起后，到达实时binder驱动，在不打断正在处理的binder请求的前提下，按优先级排序插入到fifo队列（to-dolist）的相应位置，插入的是一套binder请求，可能在多个进程的fifo队列（to-dolist）中。插入的时间基本上按原生的binder协议来进行。

在分离于普通binder的模式下，由于有两个binder驱动，而servicemanager也是一种特殊的binder服务，也需要与binder驱动通讯。所以这里就存在两种设计，第一种有一个专门服务于实时binder的servicemanager，binder库只要区分出是哪个ipcthreadstate类的实例。就可以访问到相应的servicemanager，从而得到正确的服务，这种设计，系统中存在两个servicemanager。第二种是系统中只存在一个servicemanager，实时binder在需要servicemanager的服务时，通过一个特殊的接口找到普通binder的ipcthreadstate类的实例，从而访问普通binder驱动来获得服务。由于servicemanager的服务只在binder接口初始化时调用，所以这种设计对实时性能也基本上没有影响。

所述内嵌于普通binder的模式，系统中只存一个binder驱动，每个用户进程也只有一个ipcthreadstate类的实例。binder库中有特定于实时binder请求的接口或接口附加的参数，以区分是实时binder请求还是普通binder请求。当binder驱动向ipcthreadstate类实例请求spawn线程时，通过特定参数或是binder协议中特定的命令，指明需要创建的线程是硬实时或软实时线程，ipcthreadstate类实例将创建相应的线程以在这样线程中处理实时binder请求。在binder驱动中，在每个用户进程对应的binder_proc结构中，为实时binder请求专门维护了实时binder的等待队列rt_wait_queue和实时binder的fifo队列rt_todo_list。另外，实时binder的fifo队列的数据结构中也有标志来指明它是否来自实时binder请求。通过这种设计，减少了实时binder请求被非实时binder请求竞争的可能性。虽然内嵌于普通binder的模式没有分离于普通binder的模式来的彻底，但它也有优点，即系统中只有一个binder驱动，一个进程中只有一个ipcthreadstate类的实例。

本实施例中，以系统中同时配置有分离于普通binder的模式和内嵌于普通binder的模式为例进行具体说明，针对每一次的binder请求都执行以下步骤：

步骤s1:读取配置或由用户调用的接口获得用户选用哪种模式，若选用分离于普通binder的模式则执行步骤s2-1，若选用内嵌于普通binder的模式则执行步骤s3-1;

步骤s2-1：上层的binder服务类和接口类，以及binder核心类可以区分出binder请求性质，若是实时binder请求则找到实时的ipcthreadstate类实例，若是普通binder请求则找到普通的ipcthreadstate类实例；

步骤s2-2：实时binder请求通过实时的ipcthreadstate类实例将请求发送给实时binder驱动；实时binder驱动请求实时的ipcthreadstate类实例spawn出硬实时或软实时线程以用于处理实时binder请求；

步骤s2-3：实时binder驱动公平对待所有实时binder请求或者按优先级把它们有序地插入到对应的一个或多个进程的fifo队列中；

s3-1:由binder库中的特殊接口或接口参数标明binder请求是一个实时binder请求；

s3-2:binder驱动向ipcthreadstate类实例请求spawn线程时，通过特定参数或是binder协议中特定的命令，指明需要创建的线程是硬实时或软实时线程，ipcthreadstate类实例将创建相应的线程以在这样线程中处理实时binder请求；

s3-3：在每个用户进程对应的binder_proc结构中，为实时binder请求专门维护了实时binder的等待队列rt_wait_queue和实时binder的fifo队列rt_todo_list。

按照上述实施例，便可很好地实现本发明。值得说明的是，基于上述结构设计的前提下，为解决同样的技术问题，即使在本发明上做出的一些无实质性的改动或润色，所采用的技术方案的实质仍然与本发明一样，故其也应当在本发明的保护范围内。