CN116149867A - 资源调度方法及设备 - Google Patents

Abstract

本申请实施例提供了一种资源调度方法及设备。资源调度方法包括：获取与任务轮询操作关联的系统调用指令；基于系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源；对空闲的系统计算资源进行资源调度操作。本实施例中，通过获取与任务轮询操作关联的系统调用指令，基于系统调用指令确定用于实现任务处理操作的空闲的系统计算资源，而后可以对所有空闲的系统计算资源进行资源调度操作，有效地实现了对待处理任务以及系统计算资源进行灵活调度操作，这样不仅能够保证任务处理的稳定可靠性，并且也提高了系统计算资源的利用率，进一步提高了该方法的实用性。

Description

资源调度方法及设备

技术领域

本申请涉及网络技术领域，尤其涉及一种资源调度方法及设备。

背景技术

目前，在5G的应用场景中，单一5G实例关联的核心处理器（Central ProcessingUnit，简称CPU）资源往往以隔离的方式分配给这个实例，即一个工作线程绑定有固定的CPU资源，为了确保此实例能够处理较大流量，供应商通常会过度分配CPU资源。

然而，对于5G实例所分配的CPU资源而言，即使使得实例提供其最大流量，也会存在一定数量的CPU资源根本没有被使用的情况。由于该5G实例占用的CPU核是隔离分配的，因此，上述未使用的CPU资源不能被其他实例所使用，这样造成了CPU资源的浪费。

发明内容

本申请实施例提供一种资源调度方法及设备，能够对任务与系统计算资源之间进行灵活调度操作，从而可以提高系统计算资源的利用率。

第一方面，本申请实施例提供了一种资源调度方法，包括：

获取与任务轮询操作关联的系统调用指令；

基于所述系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源；

对空闲的系统计算资源进行资源调度操作。

第二方面，本申请实施例提供了一种资源调度装置，包括：

第一获取模块，用于获取与任务轮询操作关联的系统调用指令；

第一确定模块，用于基于所述系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源；

第一处理模块，用于对空闲的系统计算资源进行资源调度操作。

第三方面，本申请实施例提供了一种电子设备，包括：存储器、处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行时实现上述第一方面所示的资源调度方法。

第四方面，本发明实施例提供了一种计算机存储介质，用于储存计算机程序，所述计算机程序使计算机执行时实现上述第一方面所示的资源调度方法。

第五方面，本发明实施例提供了一种计算机程序产品，包括：计算机程序，当所述计算机程序被电子设备的处理器执行时，使所述处理器执行上述第一方面所示的资源调度方法中的步骤。

第六方面，本发明实施例提供了一种资源调度方法，应用于专网的资源调度云平台，所述方法包括：

获取与任务轮询操作关联的系统调用指令；

基于所述系统调用指令，确定用于实现任务处理操作的空闲的云计算资源；

对空闲的云计算资源进行资源调度操作。

第七方面，本发明实施例提供了一种专网的资源调度云平台，包括：

第四获取模块，用于获取与任务轮询操作关联的系统调用指令；

第四确定模块，用于基于所述系统调用指令，确定用于实现任务处理操作的空闲的云计算资源；

第四处理模块，用于对空闲的云计算资源进行资源调度操作。

第八方面，本申请实施例提供了一种电子设备，包括：存储器、处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行时实现上述第六方面所示的资源调度方法。

第九方面，本发明实施例提供了一种计算机存储介质，用于储存计算机程序，所述计算机程序使计算机执行时实现上述第六方面所示的资源调度方法。

第十方面，本发明实施例提供了一种计算机程序产品，包括：计算机程序，当所述计算机程序被电子设备的处理器执行时，使所述处理器执行上述第六方面所示的云资源调度方法中的步骤。

本申请实施例提供的资源调度方法及设备，通过获取与任务轮询操作关联的系统调用指令，由于系统调用指令往往与待处理任务的任务执行状态相关，因此，在获取到系统调用指令之后，则可以基于系统调用指令确定用于实现任务处理操作的空闲的系统计算资源，而后可以对所有空闲的系统计算资源进行资源调度操作，从而有效地实现了对待处理任务与系统计算资源进行灵活调度操作，这样不仅能够保证任务处理的稳定可靠性，并且也提高了系统计算资源的利用率，进一步提高了该方法的实用性，有利于市场的推广与应用。

附图说明

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

图1为相关技术提供的5G实例的架构示意图；

图2为相关技术提供的物理层的下行链路消息处理过程的示意图；

图3为相关技术提供的5G中的任务队列的示意图；

图4为本申请实施例提供的一种资源调度方法的原理示意图；

图5为本申请实施例提供的一种资源调度方法的流程示意图；

图6为本申请实施例提供的基于所述系统调用指令，确定用于实现任务处理操作的空闲的核心处理器CPU资源的流程示意图；

图7为本申请实施例提供的另一种资源调度方法的流程示意图；

图8为本申请实施例提供的获取所述当前处理任务在预设任务队列中的排队时长的流程示意图；

图9为本申请实施例提供的任务轮询操作的示意图；

图10为本申请实施例提供的不同工作流所需要的CPU运行周期的示意图；

图11为本申请实施例提供的基于所述排队时长，检测当前处理任务的数量与所分配的CPU资源之间是否匹配的流程示意图；

图12为本申请实施例提供的任务线程各自对应的内存空间的示意图；

图13为本申请应用实施例提供的一种资源调度方法的原理示意图；

图14为本申请实施例提供的一种车辆控制方法的流程示意图；

图15为本申请实施例提供的一种车辆控制方法的场景示意图；

图16为本申请实施例提供的一种虚拟现实设备的控制方法的流程示意图；

图17为本申请实施例提供的一种资源调度装置的结构示意图；

图18为与图17所示实施例提供的专网设备对应的电子设备的结构示意图；

图19为本申请实施例提供的一种车辆控制装置的结构示意图；

图20为与图19所示实施例提供的车辆控制装置对应的电子设备的结构示意图；

图21为本申请实施例提供的一种虚拟现实设备的控制装置的结构示意图；

图22为与图21所示实施例提供的虚拟现实设备的控制装置对应的电子设备的结构示意图；

图23为本申请实施例提供的一种资源调度方法的原理示意图；

图24为本申请实施例提供的一种专网的资源调度云平台的结构示意图；

图25为与图24所示实施例提供的专网的资源调度云平台对应的电子设备的结构示意图。

具体实施方式

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

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多种”一般包含至少两种，但是不排除包含至少一种的情况。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测（陈述的条件或事件）”可以被解释成为“当确定时”或“响应于确定”或“当检测（陈述的条件或事件）时”或“响应于检测（陈述的条件或事件）”。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的商品或者系统中还存在另外的相同要素。

另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

术语定义：

5GC：5th Generationcore Network ，5G核心网，是5G移动网络的核心，它为最终用户建立可靠、安全的网络连接，并提供对其服务的访问。

RAN：Radio Access Network，无线接入网。

eMBB：Enhanced Mobile Broadband，增强型移动宽带，5G三个典型场景之一。

URLLC：Ultra-Reliable Low-Latency Communications，超可靠低延迟通信，5G三个典型场景之一。

BBU：Baseband Unit，基带处理单元。

UE：User Equipment，用户设备，连接基站的用户终端设备。

FlexRAN：目前由开发商提供的开源的O-RAN实现，是当前较成熟的开源实现。

UL/DL：UpLink/DownLink，上行链路/下行链路，分别对应终端到网络侧/网络侧到终端。

RTC：Run-To-Complete，运行至终结，即任务一旦开始不会暂停，直到运行结束。

为了方便本领域技术人员理解本申请实施例所提供的技术方案，下面对相关技术进行简要说明：首先，参考附图1所示，提供了能够产生5G实例的一个网络架构，该架构可以包括基站RAN、与基站RAN通信连接的5G软件，其中，5G软件包括分布式单元(DistributedUnit，简称DU)、集中式单元(Centralized Unit，简称CU) 和5G核心网，上述的DU包括物理层信号处理（Physical Layer，简称PHY）、媒体介入控制层（Media Access Control，简称MAC）和无线链路控制（Radio Link Control，简称RLC），CU包括分组数据汇聚协议(PacketData Convergence Protocol，简称PDCP)和无线电资源控制(RadioResourceControl，简称RRC)。

由于在5G场景中，5G任务往往会定义为5G vRAN生成的运行至终结(Run ToComplete，简称RTC)任务。5G vRAN可以生成或者包括数以千计的此类RTC任务。图 2展示了DU中物理层的下行链路(DL)消息处理过程，该消息处理过程往往包括对消息进行编码（encoding）、调制（modulation）、预编码（precoding）以及逆快速傅里叶变换操作（IFFT）等等，一般情况下，对于能够实现某一个功能的5G任务而言，往往会被拆分为多个5G RTC任务，而RTC任务一旦开始执行，则不能中断。

在需要执行多个5G任务时，多个任务往往是基于任务队列进行调度的，具体的，参考附图3所示，新生成的5G任务可以被插入到一组任务队列中，然后，与特定CPU核关联的工作线程在完成前一个任务后从任务队列中获取任务，一旦任务被工作线程获取，则会以运行到完成模式来执行，此时，每个工作线程往往绑定有对应的CPU核，这样可以满足基站对实时性的较高要求。

然而，上述的实现方式容易造成CPU资源的浪费，具体的，CPU资源浪费的两个来源包括：隔离部署和用户态-内核态切换：

（1）隔离部署和过度分配造成的CPU浪费：CPU资源以隔离的方式分配给一个5G实例，为了确保此实例能够处理最大流量，供应商通常会过度分配CPU资源。经过观测显示，商用5G软件为其DU实例分配了24个CPU核。不幸的是，即使DU实例提供其最大流量，即800Mbps下行链路和120Mbps上行链路流量，也会存在30.5%∼33.8%的CPU 核根本没有被使用。由于该5G实例拥有的CPU核数是隔离分配的，因此，未使用的30.5%∼33.8%的CPU核不能被其他5G实例使用，尤其是在部署多个5G实例时，则会存在CPU资源的浪费问题。

（2）用户态-内核态切换造成的CPU浪费：在执行5G任务时，用户态-内核态切换也会造成巨大的CPU浪费。经过研究发现，在执行任务处理操作的过程中，往往存在有约10.5%∼61.9%的CPU 核忙于用户态-内核态的切换，而不是处理5G任务。经过研究发现，在5G工作线程完成5G任务之后，几乎所有的供应商都要求该工作线程执行nanosleep函数以释放其CPU 核（一般设置为5us）；其中，nanosleep函数会导致当前的线程将暂停执行,直到预设参数所指定的时间间隔，在执行nanosleep函数之后，可以用来防止内核饥饿和确保实例的稳定性，特别是对于在CPU隔离模式下运行的线程。每次执行nanosleep函数，操作系统都要进行一次用户态-内核态切换，因为nanosleep函数运行在内核态，5G软件运行在用户态，而调用nanosleep函数的频率太高，以至于大量CPU 运行周期被用户态-内核态切换消耗，而不是处理5G任务，尤其是在流量较低的时候。此外，由于5G实例中始终存在多个工作线程，因此在任务轮询期间涉及进程间的通信和同步操作，这也引入了系统调用和用户内核之间的切换操作。

为了解决上述技术问题，相关技术提供了几种解决方案，具体的：

解决方案1，基于基带处理单元池（BBUPooling）的理念来解决上述技术问题，上述的基带处理单元池的核心理念是在多个小区之间复用计算资源。通常情况下，BBU中的小区单独处理任务，而基带处理单元池则是统一处理所有小区中来自不同用户终端UE的任务，相当于创建了一个大的BBU负责更多的UE。因此，不同UE的负载波动可以相互补偿，避免了单个UE的负载波动造成的资源浪费。

解决方案2，通过在5G RAN软件中修改代码，实现对流量特征和信噪比等信息的暴露，然后基于所检测的流量特征和信噪比等特征实现全局资源调度，能够使多个5G软件在单台服务器上部署运行。

解决方案3，将5G RAN和第三方应用程序共同部署来优化资源的利用，即将同一组CPU资源分配给5G RAN和第三方应用程序，系统中的调度程序会预测5G任务处理的执行时间，而后调度程序可以基于执行时间以足够快的速度使系统能够保留所需的最少CPU核数用于5G任务，其余用于通用工作负载，即第三方应用程序。

解决方案4，为数据中心应用提供了调度框架，通过调度框架保障低时延的同时维持高吞吐，进行CPU核映射的时候给应用尽可能分配少的CPU 核，以提升利用率。

然而，上述的各个解决方案均存在各自对应的缺陷，具体的：对于上述解决方案1而言，由于是将多个5G实例进行统一管理，流量在多个5G实例中分发处理，然而，系统进行资源分发的优化粒度较大，且仍然属于资源超额分配部署模式，无法充分利用空闲资源。对于上述解决方案2而言，不仅需要修改5G应用代码，暴露需要的一些关键指标，不利于信息的安全程度，另外，系统的调度周期往往为秒级，无法快速及时地响应流量的波动。对于上述解决方案3而言，虽然实现了细粒度资源优化，但是无法支持多个5G实例共享资源运行。此外，需要专业的统计学专家进行预测程序实现，而且需要修改5G厂商的代码实现，从而无法高效地迁移到其他5G环境。对于上述解决方案4而言，需要 5G RAN 实例来适应自定义调度应用程序编程接口（Application Programming Interface,简称API）实现，这使得适应工作变得复杂， 此外，调度速度和调度策略会导致显着的延迟开销，这违反了 5G 延迟和服务等级协议（Service-Level Agreement，简称SLA） 要求。

为了能够提高CPU资源的利用率，本实施例提供了一种资源调度方法及设备，其中，参考附图4所示，本实施例提供的资源调度方法的执行主体可以为资源调度装置，需要注意的是，该资源调度装置可以实现为本地服务器或者云端的服务器，此时，该资源调度方法可以在云端来执行，在云端可以部署有若干计算节点（云服务器），每个计算节点中都具有计算、存储等处理资源。在云端，可以组织由多个计算节点来提供某种服务，当然，一个计算节点也可以提供一种或多种服务。云端提供该服务的方式可以是对外提供服务接口，用户调用该服务接口以使用相应的服务。服务接口包括软件开发工具包（SoftwareDevelopment Kit，简称SDK）、应用程序接口（Application Programming Interface，简称API）等形式。

针对本发明实施例提供的方案，云端可以提供有资源调度服务接口，用户通过用户终端UE调用该资源调度接口，以向云端触发调用该资源调度接口的请求。云端确定响应该请求的计算节点，利用该计算节点中的处理资源执行资源调度的具体处理操作。

该资源调度装置可以通信连接有基站RAN和核心网，在一些实例中，资源调度装置的部署位置可以与基站运行软件所在服务器的部署位置相一致；上述的基站RAN可以通信连接有一个或多个用户终端UE，用户终端UE可以是任何具有一定数据传输能力的计算设备，具体实现时，用户终端UE可以是手机、个人电脑PC、平板电脑、设定应用程序等等。此外，用户终端UE的基本结构可以包括：至少一个处理器。处理器的数量取决于用户终端UE的配置和类型。用户终端UE也可以包括存储器，该存储器可以为易失性的，例如随机存取存储器（Random Access Memory，简称RAM），也可以为非易失性的，例如只读存储器（Read-OnlyMemory，简称ROM）、闪存等，或者也可以同时包括两种类型。存储器内通常存储有操作系统（Operating System，简称OS）、一个或多个应用程序，也可以存储有程序数据等。除了处理单元和存储器之外，用户终端UE还包括一些基本配置，例如网卡芯片、IO总线、显示组件以及一些外围设备等。可选地，一些外围设备可以包括，例如键盘、鼠标、输入笔、打印机等。其它外围设备在本领域中是众所周知的，在此不做赘述。

资源调度装置是指可以在网络虚拟环境中提供资源调度操作的设备，通常是指利用网络进行信息规划以及资源调度操作的装置。在物理实现上，资源调度装置可以是任何能够提供计算服务，响应于系统调用指令，并可以基于系统调用指令进行系统调用操作的设备，例如：可以是集群服务器、常规服务器、云服务器、云主机、虚拟中心等，其中，系统调用指令或者系统调用命令用于供用户实现通过资源调度装置可以调用位于系统内核中的子程序，上述的子程序用于实现预设系统功能。系统调用装置的构成主要包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似。

在上述本实施例中，基站与资源调度装置之间可以进行网络连接，该网络连接可以是无线或有线网络连接。若基站可以与资源调度装置是通信连接，该移动网络的网络制式可以为2G（GSM）、2.5G（GPRS）、3G（WCDMA、TD-SCDMA、CDMA2000、UTMS）、4G（LTE）、4G+（LTE+）、WiMax、5G、6G等中的任意一种。

资源调度装置，用于获取与任务轮询操作关联的系统调用指令，系统调用指令的数量可以为一个或多个，不同的系统调用指令可以对应有不同的待处理任务，由于系统调用指令往往与待处理任务的任务执行状态相关，因此，在获取到系统调用指令之后，则可以基于系统调用指令确定用于实现任务处理操作的空闲的系统计算资源，空闲的系统计算资源中可以包括基于系统调用指令所释放的系统计算资源和/或其他空闲的系统计算资源，并且，上述的系统计算资源可以包括以下至少之一个资源类型：核心处理器（CentralProcessing Unit，简称CPU）资源、图形处理器(Graphic Processing Unit，简称GPU)资源、通用图形处理器（General-Purpose Graphics Processing Unit，简称GPGPU）资源等等，本领域技术人员可以根据具体的应用场景或者应用需求对系统计算资源进行灵活调整和配置，在获取到空闲的系统计算资源之后，可以对空闲的系统计算资源进行资源调度操作，从而有效地实现了对待处理任务和所对应的系统计算资源进行重新调度操作，进一步提高了该方法的实用性，有利于市场的推广与应用。

下面结合附图，对本发明的一些实施方式作详细说明。在各实施例之间不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

参考附图5所示，本实施例提供了一种资源调度方法，该方法的执行主体为资源调度装置，可以理解的是，该资源调度装置可以实现为软件、或者软件和硬件的组合，具体的，在资源调度装置实现为硬件时，其具体可以是具有资源调度能力的各种电子设备。当资源调度装置实现为软件时，其可以安装在上述的电子设备中，在一些实例中，资源调度装置可以部署在分布式单元DU或者集中式单元CU中；具体的，该资源调度方法可以包括：

步骤S501：获取与任务轮询操作关联的系统调用指令。

其中，资源调度装置可以对一个或多个待处理任务分配相对应的系统计算资源，并能够针对所分配的系统计算资源进行调度操作，在一些实例中，系统计算资源可以包括以下至少之一个资源类型：核心处理器（Central Processing Unit，简称CPU）资源、图形处理器(Graphic Processing Unit，简称GPU)资源、通用图形处理器（General-PurposeGraphics Processing Unit，简称GPGPU）资源等等，本领域技术人员可以根据具体的应用场景或者应用需求对系统计算资源进行灵活调整和配置。

为了能够实现对待处理任务与系统计算资源进行灵活调度操作，资源调度装置可以主动或者被动地进行任务轮询操作，在一些实例中，任务轮询操作可以基于预设的任务轮询周期进行，上述的任务轮询周期可以为1us/次、2us/次或者1.5us/次等等，并且，上述的任务轮询周期可以是预先配置有或者用户主动配置的。

在另一些实例中，任务轮询操作不仅可以通过预设的任务轮询周期来执行，还可以在资源调度装置的预设参数满足预设状态时触发执行，例如：在同一时刻资源调度装置所检测的待处理任务的数量大于或等于预设数量时，则执行任务轮询操作；在同一时刻资源调度装置所对应的启动工作线程的数量大于或等于预设数量时，则执行任务轮询操作等等。

在资源调度装置进行任务轮询操作的过程中或者之后，可以获取由工作线程或者系统所发送的系统调用指令，该系统调用指令即为与任务轮询操作关联的调用指令，所获得的系统调用指令的数量可以为一个或多个，每个系统调用指令往往与一待处理任务/一个工作线程相对应。举例来说，在执行依次任务轮询操作之后，可以获取到与任务轮询操作关联的系统调用指令1和系统调用指令2，上述的系统调用指令1可以对应于待处理任务a，系统调用指令2可以对应于待处理任务b。

需要注意的是，在利用资源调度装置针对应用程序进行资源调度操作时，不同的应用程序可以对应有不同的系统调用指令，或者，在不同的应用场景中，针对相同的应用程序也可以对应有不同的系统调用指令。因此，为了能够满足资源调度的稳定可靠性，在获取与任务轮询操作关联的系统调用指令之前，本实施例中的方法还可以包括：获取待调度的应用程序；基于应用程序，确定与任务轮询操作相关的系统调用指令类型；该系统调用指令类型可以为应用程序所对应的所有调用指令类别或者部分调用指令类别等；基于系统调用指令类型，确定与应用程序相对应的能够参与资源调度操作的所有类型的系统调用指令。

具体的，为了能够稳定地实现资源调度操作，可以获取待调度的应用程序，待调度的应用程序可以是指资源调度装置能够进行管理的任意应用程序，在一些实例中，待调度的应用程序可以是预先部署在资源调度装置中的应用程序或者是与资源调度装置通信连接的应用程序，所获得的待调度的应用程序的数量可以为一个或多个。由于不同的应用程序可以对应有不同的能够参与资源调度操作的系统调用指令，因此，在获取到应用程序之后，可以基于应用程序来确定与任务轮询操作相关的系统调用指令类型，系统调用指令类型往往是基于预设的经验信息或者用户输入的交互操作所确定的，而后可以基于系统调用指令类型来确定与应用程序相对应的能够参与资源调度操作的所有类型的系统调用指令，从而有效地保证了对系统调用指令进行获取的准确可靠性。

步骤S502：基于系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源。

对于系统调用指令而言，由于系统调用指令与待处理任务的任务处理状态相关，例如，在待处理任务执行完毕之后，系统或者工作线程可以生成相对应的系统调用指令等等；而待处理任务的任务处理状态与空闲的系统计算资源存在直接关系，这样在获取到系统调用指令之后，可以对系统调用指令进行分析处理，确定用于实现任务处理操作的空闲的系统计算资源，在系统计算资源包括CPU资源时，空闲的CPU资源可以包括用于实现任务处理操作的空闲CPU核。

在一些实例中，空闲的系统计算资源可以通过预设映射关系来确定，此时，基于系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源可以包括：获取用于对系统调用指令进行分析处理的预设映射关系，基于预设映射关系将与系统调用指令相对应的系统计算资源确定为待释放系统计算资源，将待释放系统计算资源与当前所有的空闲系统计算资源确定为用于实现任务处理操作的空闲的系统计算资源；或者，将待释放系统计算资源确定为空闲的系统计算资源。

步骤S503：对空闲的系统计算资源进行资源调度操作。

在获取到空闲的系统计算资源之后，为了能够提高系统计算资源的利用率，可以针对当前的待处理任务对空闲的系统计算资源进行资源调度操作。举例来说，以CPU核作为系统计算资源为例，在t1时刻，资源调度装置所对应的待处理任务可以包括：任务1、任务2和任务3，任务1分配有第一CPU核，任务2分配有第二CPU核，任务3分配有第三CPU核，空闲的CPU核可以包括：第四CPU核、第五CPU核、第六CPU核、第七CPU核以及第八CPU核；在经过任务轮询操作时，获取到与任务2相对应的系统调用指令，则说明此时任务2所分配第二CPU核需要被释放，可以获取到空闲的CPU核，此时的空闲的CPU核可以包括：第二CPU核、第四CPU核、第五CPU核、第六CPU核、第七CPU核以及第八CPU核；在t2时刻，t2＞t1，若当前的待处理任务可以包括：任务1、任务3、任务4以及任务5时，则可以针对上述的当前的待处理任务对空闲的CPU资源进行资源调度操作，任务1分配有第一CPU核，任务3分配有第三CPU核，任务4可以分配有第五CPU核，任务5可以分配第二CPU核等等，从而有效地实现了资源的灵活调度操作。

本实施例提供的资源调度方法，通过获取与任务轮询操作关联的系统调用指令，由于系统调用指令往往与待处理任务的任务执行状态相关，因此，在获取到系统调用指令之后，则可以基于系统调用指令确定用于实现任务处理操作的空闲的系统计算资源，而后可以对空闲的系统计算资源进行资源调度操作，由于待处理任务与所对应的系统计算资源之间并没有固定的绑定关系，从而实现了对系统计算资源的灵活调度操作，这样不仅能够保证任务处理的稳定可靠性，并且也提高了系统计算资源的利用率，保证了该方法的实用性。

在上述实施例的基础上，参考附图6所示，对于空闲的系统计算资源而言，其不仅可以通过预设映射关系来确定，还可以通过确定待处理任务的任务完成时间来确定，此时，基于系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源可以包括：

步骤S601：基于系统调用指令，确定待处理任务的任务完成时间。

在获取到系统调用指令之后，可以基于系统调用指令来确定待处理任务的任务完成时间，上述的待处理任务可以是指预设应用场景中的RTC任务，其具体可以是指能够实现某一个完整功能的预设任务，或者，也可以是指能够某一个完整功能中的一部分的子任务，另外，待处理任务可以对应有一个或多个RAN，即本实施例中的资源调度装置可以同时对来自一个或多个RAN的待处理任务进行统一的资源调度操作。

本实施例对于任务完成时间的具体确定方式不做限定，在一些实例中，任务完成时间可以通过系统调用指令所对应的时间戳信息来确定，此时，基于系统调用指令，确定待处理任务的任务完成时间可以包括：获取与系统调用指令相对应的时间戳信息，时间戳信息用于标识进入系统调度操作的时间；基于时间戳信息，确定待处理任务的任务完成时间。

具体的，与系统调用指令相对应的时间戳信息可以是指位于系统调用指令内的时间戳信息或者与系统调用指令存在关联关系的时间戳信息，该时间戳信息能够标识进入系统调度操作的时间信息。在时间戳信息位于系统调用指令内时，获取与系统调用指令相对应的时间戳信息可以包括：对系统调用指令进行信息提取操作，获取与系统调用指令相对应的时间戳信息。在时间戳信息与系统调用指令存在关联关系时，获取与系统调用指令相对应的时间戳信息可以包括：响应于系统调用指令，获取相对应的调用函数，调用函数中对应有时间戳信息，通过调度函数来确定时间戳信息，从而有效地保证了对时间戳信息进行获取的准确可靠性。其中，与系统调度指令相关联的调用函数可以存储在预设区域中，在运行调用函数时，资源调度装置处于用户态，而不会进入至内核态，这样可以尽量减少用户态与内核态之间的切换操作。

由于时间戳信息用于标识进入系统调度操作的时间，而进入系统调度操作的时间与待处理任务的任务完成时间几乎相同，因此，在获取到时间戳信息之后，可以基于时间戳信息来确定待处理任务的任务完成时间，在一些实例中，将时间戳信息直接确定为待处理任务的任务完成时间。在另一些实例中，将时间戳信息与预设时间偏差的差值确定为待处理任务的任务完成时间，例如：时间戳信息为

，预设时间偏差为/>

，则任务完成时间可以为/>

，其中，/>

可以为0.001us、0.002us、0.0005us等等，本领域技术人员可以根据具体的应用场景或者应用需求对/>

的数值进行灵活设置和调整。

步骤S602：基于任务完成时间，确定用于实现任务处理操作的空闲的系统计算资源。

对于待处理任务而言，本实施例中的待处理任务与所分配的系统计算资源之间并不存在固定的绑定关系，当待处理任务执行完毕之后，则会释放为上述待处理任务所分配的系统计算资源，即所占用的系统计算资源由占用状态调整为空闲状态。因此，在获取到任务完成时间之后，则可以对任务完成时间进行分析处理，以确定用于实现任务处理操作的空闲的系统计算资源。在一些实例中，该空闲的系统计算资源可以为经过释放的与任务完成时间相对应的系统计算资源，此时，空闲的系统计算资源的数量与任务完成时间的数量相同，在任务完成时间的数量为3个时，则可以确定3个用于实现任务处理操作的空闲的系统计算资源。

在另一些实例中，空闲的系统计算资源不仅可以包括经过释放的与任务完成时间相对应的系统计算资源，还可以包括系统内所能够提供的未被占用的其他系统计算资源，此时，基于任务完成时间，确定用于实现任务处理操作的空闲的系统计算资源可以包括：获取待处理任务所对应的占用系统计算资源；基于任务完成时间对占用系统计算资源进行释放，获得释放系统计算资源；将释放系统计算资源和其他空闲的系统计算资源，确定为用于实现任务处理操作的空闲的系统计算资源。

举例来说，以CPU资源作为系统计算资源为例，系统所能够提供的CPU资源为八个，其中，正在执行的待处理任务有四个，那么系统中当前存在的未被占用（空闲）的CPU资源为四个。当获取到其中一个待处理任务所对应的任务完成时间时，则会基于任务完成时间对该待处理任务所对应的CPU资源进行释放，从而获得当前的释放CPU资源，释放CPU资源未被任何任务或者线程所占用，因此，可以将释放CPU资源和其他空闲的CPU资源确定为用于实现任务处理操作的空闲的CPU资源，此时，空闲的CPU资源的数量可以为五个。

本实施例中，基于系统调用指令确定待处理任务的任务完成时间，而后基于任务完成时间确定用于实现任务处理操作的空闲的系统计算资源，有效地保证了对空闲的系统计算资源进行确定的灵活可靠性，而后对空闲的系统计算资源进行调度，有效地提高了系统计算资源的利用率。

在上述任意一个实施例的基础上，参考附图7所示，本实施例中的方法不仅能够实现上述的基于系统调用指令对系统计算资源进行安全调度的操作，还能够实现对系统计算资源进行主动调度操作，此时，本实施例中的方法还可以包括：

步骤S701：检测当前处理任务的数量与所分配的系统计算资源之间是否匹配。

对于待处理任务（可以是来自一个RAN的一个或多个待处理任务，也可以是指来自不同RAN的多个待处理任务）而言，为了能够实现任务处理操作，会为该待处理任务分配一定数量的系统计算资源，这里的分配可以是按照预设策略或者预设参数进行资源分配操作的，以基于所分配的CPU资源执行相对应的任务处理操作。

在实际操作的过程中，由于待处理任务的数量以及状态会随着时间的变化而发生变化，因此，所分配的系统计算资源可能会出现不适配的情况，例如：待处理任务的数量较少，所分配的系统计算资源较多；或者，待处理任务的数量较多，所分配的系统计算资源较少等情况，上述情况要么会造成系统计算资源的浪费，要么无法保证任务的正常执行。

为了避免上述情况的发生，本实施例中还可以包括对系统计算资源进行主动调度的操作，为了能够实现对系统计算资源的主动调度操作，可以先检测当前处理任务的数量与所分配的系统计算资源之间是否匹配，在一些实例中，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配可以包括：获取当前处理任务的任务运行数据（例如：数量、运行状态、预计处理时长等等）以及所分配的系统计算资源，将任务运行数据与所分配的系统计算资源输入至预先训练好的机器学习模型或者神经网络模型中，而后可以获得机器学习模型或者神经网络模型所输出的检测结果，检测结果可以包括当前处理任务的数量与所分配的系统计算资源之间相匹配的结果、或者当前处理任务的数量与所分配的系统计算资源之间不匹配的结果。

在另一些实例中，检测操作不仅可以通过机器学习模型或者神经网络模型来实现，还可以通过当前处理任务在预设任务队列中的排队时长来实现，此时，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配可以包括：获取当前处理任务在预设任务队列中的排队时长；基于排队时长，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配。

具体的，为了能够对当前处理任务的数量与所分配的系统计算资源之间的匹配关系进行检测，可以获取当前处理任务在预设任务队列中的排队时长，其中，排队时长可以通过当前处理任务进入预设任务队列的开始排队时间以及当前处理任务的开始执行时间所获得，此时，排队时长=开始执行时间-开始排队时间。

由于当前处理任务在预设任务队列中的排队时长能够体现当前处理任务的数量与所分配的系统计算资源之间的匹配关系，因此，在获取到排队时长之后，可以基于排队时长来检测当前处理任务的数量与所分配的系统计算资源之间是否匹配。在一些实例中，基于排队时长，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配可以包括：获取用于对排队时长进行分析处理的预设时长范围，在排队时长位于预设时长范围之外时，则确定当前处理任务的数量与所分配的系统计算资源之间不匹配；在排队时长位于预设时长范围之内时，则确定当前处理任务的数量与所分配的系统计算资源之间相匹配，从而有效地实现了对当前处理任务的数量与所分配的系统计算资源之间是否匹配的检测操作。

步骤S702：在当前处理任务的数量与系统计算资源之间相匹配时，则保持对系统计算资源的分配状态。

步骤S702：在当前处理任务的数量与系统计算资源之间不匹配时，则对当前处理任务与系统计算资源进行重分配操作。

当获取到检测结果之后，可以基于检测结果对系统计算资源进行主动调度操作，具体的，在当前处理任务的数量与所分配的系统计算资源之间相匹配时，则说明此时所分配的系统计算资源不仅能够保证任务处理操作的正常进行，还能够保证系统计算资源的利用率，因此，可以保持当前对系统计算资源的分配状态，即对于当前处理任务以及所分配的系统计算资源不做任何改动。

在当前处理任务的数量与所分配的系统计算资源之间不匹配时，则说明此时所分配的系统计算资源可能无法保证任务处理操作的正常进行，或者，存在多余空闲的系统计算资源未被利用，此时，为了能够提高系统计算资源的利用率，可以对当前处理任务与所分配的系统计算资源进行重新分配操作，具体的，重新分配操作可以按照预设分配策略进行，只要能够保证任务处理操作的正常进行，且提高系统计算资源的利用率即可，在此不再赘述。

本实施例中，通过检测当前处理任务的数量与所分配的系统计算资源之间是否匹配，在当前处理任务的数量与系统计算资源之间相匹配时，则保持对系统计算资源的分配状态，在当前处理任务的数量与系统计算资源之间不匹配时，则对当前处理任务与系统计算资源进行重分配操作，有效地实现了可以根据当前处理任务的数量与所分配的系统计算资源的检测结果主动对系统计算资源进行调度操作，有利于在保证任务正常执行的同时，提高系统计算资源的利用率，进一步提高了该方法的实用性。

在上述实施例的基础上，参考附图8所示，对于排队时长而言，其不仅可以通过当前处理任务进入预设任务队列的开始排队时间以及当前处理任务的开始执行时间所获得，还可以通过预设任务队列的队列状态来获得，此时，获取当前处理任务在预设任务队列中的排队时长，包括：

步骤S801：获取当前处理任务所对应的预设任务队列的队列状态。

在通过开始排队时间和开始执行时间来获取到排队时长时，此时的排队时长往往是一个十进制的数据，并且，不同的排队时长会对应有不同的数据，这样不仅会增加对排队时长进行分析处理的时间，并且还增加了对排队时长进行分析处理的复杂程度。因此，为了能够获取到当前处理任务在预设任务队列中的排队时长，同时减少数据处理的时长和复杂程度，在获取到当前处理任务之后，可以确定当前处理任务所对应的预设任务队列，而后可以获取预设任务队列的队列状态。在一些实例中，获取当前处理任务所对应的预设任务队列的队列状态可以包括：对预设任务队列进行扫描处理，检测预设任务队列中是否存在待处理任务；在预设任务队列中存在待处理任务时，则确定预设任务队列的队列状态为非空；在预设任务队列中不存在待处理任务时，则确定预设任务队列的队列状态为空。

在另一些实例中，队列状态不仅可以通过对预设任务队列进行扫描处理获得，还能够通过两次连续的系统调用指令来获得，此时，获取当前处理任务所对应的预设任务队列的队列状态可以包括：获取当前处理任务所对应的两次连续的系统调用指令；确定两次连续的系统调用指令之间的时间间隔；基于时间间隔，确定当前处理任务所对应的预设任务队列的队列状态。

为了便于理解确定队列状态的原理，参考附图9所示，对任务轮询操作过程中的任务处理过程进行简单说明，在资源调度装置进行任务轮询操作时，在任务队列中存在待处理任务时，则工作线程在任务轮询操作中的轮询结果为成功获取到待处理任务，而后可以按照工作流1的走向进行相对应的处理操作，具体的，可以针对待处理任务进行任务执行操作，并可以获得并提交任务执行操作相对应的执行结果，而后可以退出当前的检查操作，进行下一次的任务轮询操作；在任务队列中不存在待处理任务时，则工作线程在任务轮询操作的轮询结果为未成功获取到待处理任务（失败），而后可以按照工作流2进行相对应的处理操作，具体的，可以直接退出检查操作，并可以进行下一次的任务轮询操作。

由于工作线程分别按照工作流1和工作流2进行数据处理操作时所需要的时间是不同的，具体的，工作流1所需要的时间往往大于工作流2所需要的时间，按照工作流1中进行下一次任务轮询操作时，两次轮询操作的时间间隔较长，在按照工作流2中进行下一次任务轮询操作时，两次任务轮询操作的时间间隔较短，而上述的时间间隔与预设任务队列的队列状态存在关联关系，因此，可以获取当前处理任务所对应的两次连续的系统调用指令，而后确定两次连续的系统调用指令之间的时间间隔；并基于时间间隔来确定当前处理任务所对应的预设任务队列的队列状态。

具体的，在针对当前处理任务进行多次任务轮询操作时，可以获取当前处理任务所对应的两次连续的系统调用指令，而后可以确定两次连续的系统调用指令各自对应的指令调用时间，基于两次连续的系统调用指令各自对应的指令调用时间确定两次连续的系统调用指令之间的时间间隔。

在获取到时间间隔之后，可以对时间间隔进行分析处理，从而可以确定当前处理任务所对应的预设任务队列的队列状态，在一些实例中，基于时间间隔，确定当前处理任务所对应的预设任务队列的队列状态可以包括：在时间间隔大于第一间隔阈值时，则说明调度待处理任务的数据流为工作流1，从而可以确定队列状态为非空；在时间间隔小于第二间隔阈值时，则说明调度待处理任务的数据流为工作流2，从而可以确定队列状态为空，其中，第二间隔阈值小于第一间隔阈值。在另一些实例中，用于对时间间隔进行分析处理的间隔阈值的数量可以为一个，此时，基于时间间隔，确定当前处理任务所对应的预设任务队列的队列状态可以包括：在时间间隔大于间隔阈值时，则说明调度待处理任务的数据流为工作流1，从而可以确定队列状态为非空；在时间间隔小于或等于间隔阈值时，则说明调度待处理任务的数据流为工作流2，从而可以确定队列状态为空。

在又一些实例中，不仅可以通过两次连续的系统调用指令来获得预设任务队列的队列状态，还可以通过计算资源运行周期来确定预设任务队列的队列状态，此时，获取当前处理任务所对应的预设任务队列的队列状态可以包括：获取当前处理任务所对应的计算资源运行周期；基于计算资源运行周期，确定当前处理任务所对应的预设任务队列的队列状态。

其中，参考附图10所示，以CPU资源作为系统计算资源为例，通过对工作线程所对应的工作流1和工作流2的处理操作进行研究发现，工作流2在99.5%的时间内需要少于2328个CPU运行周期进行数据处理操作，而工作流1在99.5%的时间需要超过3972个CPU运行周期进行数据处理操作，由于不同的工作流所需要的CPU运行周期等计算资源运行周期不同，因此可以基于计算资源运行周期来确定预设任务队列的队列状态。具体的，可以获取当前处理任务所对应的计算资源运行周期，其中，计算资源运行周期可以通过预设算法或者预先训练好的机器学习模型对当前处理任务进行分析处理所获得。

在获取到计算资源运行周期之后，可以基于计算资源运行周期来确定当前处理任务所对应的预设任务队列的队列状态，在一些实例中，用于对计算资源运行周期进行分析处理的周期阈值可以包括第一周期阈值和第二周期阈值，此时，基于计算资源运行周期，确定当前处理任务所对应的预设任务队列的队列状态可以包括：在计算资源运行周期大于第一周期阈值时，则确定队列状态为非空；在计算资源运行周期小于第二周期阈值时，则确定队列状态为空，其中，第二周期阈值小于第一周期阈值。

在另一些实例中，用于对计算资源运行周期进行分析处理的周期阈值可以为一个，此时，基于计算资源运行周期，确定当前处理任务所对应的预设任务队列的队列状态可以包括：在计算资源运行周期大于周期阈值时，则确定队列状态为非空；在计算资源运行周期小于或者等于周期阈值时，则确定队列状态为空，从而有效地保证了对队列状态进行确定的准确可靠性。

步骤S802：在队列状态为空时，则确定排队时长为用于标识队列状态为空的第一时长。

步骤S803：在队列状态为非空时，则确定排队时长为用于标识队列状态为非空的第二时长；其中，第一时长和第二时长均为二进制信息。

在队列状态为空时，则可以确定排队时长为用于标识队列状态为空的第一时长，在队列状态为非空时，确定排队时长为用于标识队列状态为非空的第二时长；需要注意的是，第一时长和第二时长均为二进制信息，具体的，第一时长可以表达为“0”，第二时长可以表达为“1”，或者，第一时长可以表达为“1”，第二时长可以表达为“0”等等，从而有效地保证了对用于标识队列状态的排队时长进行确定的准确可靠性。

本实施例中，通过获取当前处理任务所对应的预设任务队列的队列状态，在队列状态为空时，则确定排队时长为用于标识队列状态为空的第一时长，在队列状态为非空时，则确定排队时长为用于标识队列状态为非空的第二时长；由于第一时长和第二时长均为二进制信息，这样在基于第一时长或者第二时长进行资源调度操作时，不仅保证了资源调度操作的质量和效率，并且能够降低资源调度操作的复杂程度，进一步提高了该方法的实用性。

在上述实施例的基础上，参考附图11所示，在排队时长为第一时长时，可以通过预设任务队列变空的频率信息来检测当前处理任务的数量与所分配的系统计算资源之间是否匹配，此时，本实施例中的基于排队时长，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配包括：

步骤S1101：在排队时长为第一时长时，则获取预设任务队列变空的频率信息。

在排队时长为第一时长时，则说明预设任务队列中并不存在待处理任务，并且系统计算资源存在被无效占用的情况，需要释放系统计算资源，为了进一步判断是否需要释放系统计算资源，则可以获取预设任务队列变空的频率信息。在一些实例中，获取预设任务队列变空的频率信息可以包括：在预设时间段内，获取预设任务队列变空的次数信息，基于次数信息和预设时间段来确定预设任务队列变空的频率信息。

在另一些实例中，获取预设任务队列变空的频率信息可以包括：获取与预设任务队列相对应的所有任务线程；确定所有任务线程各自对应的内存空间，内存空间配置有空信号计数器，其中，不同的任务线程所对应的内存空间相互独立；基于所有的任务线程对应的所有空信号计数器，确定预设任务队列变空的频率信息。

其中，对于预设任务队列而言，由于预设任务队列中可以包括多个待处理任务，而多个待处理任务可以由不同的任务线程进行调度并执行，因此，为了能够准确地获取预设任务队列变空的频率信息，可以获取与预设任务队列相对应的所有任务线程，参考附图12所示，一个5G实例所对应的多个待处理任务可以由任务线程1、任务线程2……任务线程N进行处理，其中，任务线程1对应有共享内存1，共享内存1中部署有空信号计数器1，任务线程2对应有共享内存2，共享内存2中部署有空信号计数器2，任务线程N对应有共享内存N，共享内存N中部署有空信号计数器N。

为了能够保证任务处理操作的质量和效率，在获取到所有任务线程之后，可以确定所有任务线程各自对应的共享内存，需要注意的是，不同的任务线程对应有不同的共享内存，上述共享内存中所存储的数据满足缓存行对齐的规则，共享内存中可以配置有空信号计数器，在每个任务线程按照工作流2进行数据处理操作时，即预设任务队列变空，则空信号计数器加1。

由于预设任务队列可以对应有多个工作线程，而每个工作线程所对应的内存空间中维护有空信号计数器，因此，可以统计所有的任务线程所对应的所有空信号计数器，而后基于所有的空信号计数器来确定预设任务队列变空的频率信息，具体的，可以将所有的空信号计数器的当前数值和与历史计数器中的数值之间的差值，而后可以基于差值确定频率信息，从而有效地保证了对频率信息进行确定的准确可靠性。

步骤S1102：基于频率信息，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配。

在获取到频率信息之后，可以基于频率信息来检测当前处理任务的数量与所分配的系统计算资源之间是否匹配。在一些实例中，基于频率信息，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配可以包括：获取预先训练好的机器学习模型或者神经网络模型，将频率信息输入至机器学习模型或者神经网络模型中，获得机器学习模型或者神经网络模型所输出的检测结果，该检测结果用于标识当前处理任务的数量与所分配的系统计算资源之间是否匹配。

在另一些实例中，预先配置有用于对频率信息进行分析处理的第一频率阈值和第二频率阈值，此时，基于频率信息，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配包括：在频率信息小于或等于第一频率阈值时，则确定当前处理任务的数量与所分配的系统计算资源不匹配，并新增用于处理当前处理任务的系统计算资源；在频率信息大于第二频率阈值时，则获取与上一次进行系统计算资源释放操作的时间间隔，基于时间间隔检测当前处理任务的数量与所分配的系统计算资源之间是否匹配；其中，第二频率阈值大于第一频率阈值；在频率信息大于第一频率阈值、且小于或等于第二频率阈值时，则确定当前处理任务的数量与所分配的系统计算资源相匹配。

在获取到频率信息、第一频率阈值和第二频率阈值之后，可以将频率信息、第一频率阈值和第二频率阈值进行分析比较，在频率信息大于第一频率阈值、且小于或等于第二频率阈值时，则确定当前处理任务的数量与所分配的系统计算资源相匹配，进而可以保持当前的资源分配状态不变。在频率信息小于或等于第一频率阈值时，即预设任务队列变空的频率较低，这样可以确定当前处理任务的数量与所分配的系统计算资源不匹配，并且，预设任务队列中存在未处理完毕的待处理任务，此时，为了能够保证任务处理的质量和效率，可以新增用于处理当前处理任务的系统计算资源，具体的，针对当前处理任务而言，每次可以新增1个系统计算资源，在新增系统计算资源之后仍然不满足任务处理的质量和效率时，可以再次新增1个系统计算资源。

在频率信息大于第二频率阈值时，则说明预设任务队列变空的频率较高，此时对于当前处理任务与所分配的系统计算资源而言，可能存在空闲的系统计算资源，为了保证任务处理的稳定可靠性，可以获取与上一次进行系统计算资源释放操作的时间间隔，而后基于时间间隔检测当前处理任务的数量与所分配的系统计算资源之间是否匹配；其中，第二频率阈值大于第一频率阈值。

具体的，在每次针对系统计算资源进行释放操作时，则可以通过预设计时器来记录系统计算资源释放操作所对应的时间信息，因此，在频率信息大于第二频率阈值时，则可以获取与上一次进行系统计算资源释放操作的时间间隔，而后可以基于时间间隔来检测当前处理任务的数量与所分配的系统计算资源之间是否匹配，在一些实例中，基于时间间隔检测当前处理任务的数量与所分配的系统计算资源之间是否匹配可以包括：在时间间隔大于预设时长阈值时，则确定当前处理任务的数量与所分配的系统计算资源不匹配，并对与当前处理任务相对应的部分空闲系统计算资源进行释放；在时间间隔小于或等于预设时长阈值时，则确定当前处理任务的数量与所分配的系统计算资源相匹配，并保持当前处理任务与系统计算资源之间的分配关系。

本实施例中，在排队时长为第一时长时，通过获取预设任务队列变空的频率信息，而后基于频率信息来检测当前处理任务的数量与所分配的系统计算资源之间是否匹配，从而有效地实现了对当前处理任务的数量与所分配的系统计算资源之间是否匹配进行检测操作，而后可以基于检测操作的结果进行资源调度操作，进一步提高了该方法的实用性。

具体应用时，参考附图13所示，以CPU资源作为系统计算资源为例，本应用实施例提供了一种针对5G RAN多实例的CPU资源调度方案，该方案不仅能够满足5G软件的高稳定性要求、5G资源调度透明性要求、5G资源调度弹性要求等，并且能够支持多个不同5G厂商的多个5G RAN实例部署及资源共享，有效优化了5G RAN环境中的CPU资源使用率。其中，该CPU资源调度方案可以包括RTC安全调度方案、主动调度方案、超快速调度方案（用于在宏观时间尺度（天/小时）和微观时间尺度（毫秒/微秒）上收集浪费的CPU 运行周期）等等。

其中，RTC安全调度方案可以确保5G任务以RTC模式执行，并且以不间断和运行到完成的模式进行资源调度操作，不会出现任何中断，具体的，该方案可以包括以下步骤：

步骤1：获取与预设应用程序相对应的待处理任务，其中，待处理任务可以为RTC任务。

步骤2：针对系统进行任务轮询操作，识别5G实例中的工作线程针对待处理任务的任务完成时间。

其中，由于任务完成时间可以与任务轮询操作所拦截或者所获得的系统调用指令相关，在待处理任务执行完毕之后，会发出系统调用指令，因此，可以通过观察和拦截系统调用指令，在不违反线程上运行任务的RTC要求的情况下，基于系统调用指令进行CPU核的分配操作。

具体的，为了能够准确地确定任务完成时间，在预设应用程序运行之前，可以配置与预设应用程序相关联的调用函数，该调用函数可以为存储在预设区域中的二进制文件，需要注意的是，在运行调用函数时，不会进入内核态。另外，由于任务完成时间与所拦截的系统调用指令存在直接关系，为了能够准确地确定任务完成时间，上述的调用函数中可以维护有时间戳信息，该时间戳信息用于标识进入系统调度操作的时间。

在进入任务轮询操作时，若获取某一工作线程针对待处理任务的系统调用指令，基于系统调用指令确定相对应的调用函数；通过调用函数中的时间戳信息确定该工作线程进入系统调度操作的时间，而后将进入系统调度操作的时间确定为任务完成时间。

需要注意的是，由于不同的预设应用程序可以对应有不同的系统调用指令，并且在一次任务轮询操作时，所获得的系统调用指令的数量可以为一个或多个，为了能够针对不同的预设应用程序所产生的RTC任务进行资源调度操作，预先构建一个能够自动识别与任务轮询操作相关的系统调用指令的工具，在获取到某一应用程序时，通过在应用程序中安装上述工具，该工具即可对应用程序所对应的所有系统调用指令进行遍历处理，从而可以确定该应用程序中适用于在任务轮询过程中进行资源调度操作的系统调用指令，其中，适用于在任务轮询操作过程中进行资源调度操作的系统调用指令可以为应用程序的所有系统调用指令中的至少一部分。

步骤3：基于任务完成时间，确定用于实现任务处理操作的空闲的CPU资源。

在获取到任务完成时间之后，可以基于任务完成时间来对待处理任务所对应的CPU资源进行释放，而后可以将所释放的CPU资源和其他空闲CPU资源确定为用于实现任务处理操作的多个空闲的CPU资源。

步骤4：对空闲的CPU资源进行资源调度操作。

在获取到空闲的CPU资源之后，可以针对待处理的RTC任务和所有空闲的CPU资源进行重新分配操作，从而实现了RTC任务的安全调度，这样不仅能够保证CPU资源的利用率，并且还能够保证任务处理的稳定可靠性。

其次，主动调度方案能够主动分配CPU核，以满足5G实例的需求，具体的，主动调度方案可以包括：

步骤21：获取当前处理任务在预设任务队列中的排队时长。

其中，主动调度方案的目标为尽量地降低5G任务违反时序的可能性，同时尽量地减少CPU资源消耗，为了达到上述目的，可以选择排队时长作为指标参数来实现主动调度操作，而选择排队时长作为指标参数有两个原因：（1）排队时长可以在不修改5G实例代码的情况下通过隐式测量获得；（2）排队时长可以指示当前CPU核的分配与5G实例的需求之间的是否匹配的关系。

对于预设任务队列而言，将5G任务的排队时长最小化可以实现上述目标，上述的排队时长可以是二进制信息，这样便于实现最小化排队时长；排队时长可以通过检查预设任务队列的状态（是否为空）来获得，具体的，如果预设任务队列不为空，则可以确定当前处理任务在预设任务队列中的排队时长为预设的第一时长；如果预设任务队列为空，则可以确定当前处理任务在预设任务队列中的排队时长为预设的第二时长。

为了能够在不修改5G软件源代码的情况下识别预设任务队列是否为空，可以通过识别工作线程所对应的数据流来识别预设任务队列是否为空，如图9所示，在进行任务轮询过程中，若工作线程成功通过预设任务队列获取到待处理任务，即预设任务队列不为空，工作线程会按照预设的工作流1来处理5G任务；若工作线程未成功通过预设任务队列获取到待处理任务，即预设任务队列为空，工作线程会按照预设的工作流2来处理5G任务，因此，通过识别工作线程是通过工作流1还是工作流2进行相对应的任务处理操作，即可识别出预设任务队列是否为空。

承接上述内容可知，只要能够识别出工作线程是通过工作流1还是工作流2进行相对应的任务处理操作，而后可以根据识别结果判断出预设任务队列是否为空。而识别出工作线程是通过工作流1还是工作流2进行相对应的任务处理操作可以包括以下几种实现方式：

实现方式一：利用工作线程在任务轮询操作过程中产生的连续两次系统调用指令之间的时间间隔来识别工作线程是通过工作流1还是工作流2进行数据处理操作。具体的，经过研究发现，由于在工作线程通过工作流1进行任务处理操作时，工作线程需要处理一个5G任务，这比工作流2只执行任务轮询和退出检查所需要的时间要长得多，即工作线程在通过工作流1进行相对应的任务处理操作所需要的时间信息1与通过工作流2进行相对应的任务处理操作所需要的时间信息2不同，一般情况下，时间信息1大于时间信息2。为了能够准确地对工作流进行识别操作，可以获取工作线程在任务轮询操作过程中产生的连续两次系统调用指令之间的时间间隔，在时间间隔大于或等于预设时间阈值时，则可以确定通过工作流1进行数据处理操作；在时间间隔小于预设时间阈值时，则可以确定通过工作流2进行数据处理操作。

实现方式二：通过待处理任务的CPU运行周期来判断工作线程是通过工作流1还是工作流2进行数据处理操作。经过研究发现，工作流2在99.5%的时间内需要少于2328个CPU运行周期，而工作流1在99.5%的时间需要超过3972个运行周期，由上可知，工作流1和工作流2所需的CPU运行周期不同，因此，可以获取待处理任务的CPU运行周期，而后将CPU运行周期可以与预设周期阈值（例如：2900、3000等等）进行分析比较，在CPU运行周期大于或等于预设周期阈值时，则确定工作线程是通过工作流1进行数据处理操作；在CPU运行周期小于预设周期阈值时，则确定工作线程是通过工作流2进行数据处理操作。

步骤22：基于排队时长，检测当前处理任务的数量与所分配的CPU资源之间是否匹配。

在排队时长为第一时长时，则说明此时的预设任务队列的队列状态为空，可能存在空闲的CPU资源未被使用，为了提高CPU资源的利用率，同时也保证任务处理的质量和效率，避免无法对新增多个任务进行稳定处理的情况，则可以获取预设任务队列变空的频率信息；进一步基于频率信息检测当前处理任务的数量与所分配的CPU资源之间是否匹配。

其中，获取预设任务队列变空的频率信息可以包括：获取与预设任务队列相对应的所有任务线程；确定所有任务线程各自对应的内存空间，内存空间配置有空信号计数器，其中，不同的任务线程所对应的内存空间相互独立；基于所有的任务线程对应的所有空信号计数器，确定预设任务队列变空的频率信息。

在获取到频率信息之后，可以对频率信息进行分析处理，以检测当前处理任务的数量与所分配的CPU资源之间是否匹配，具体的，可以将频率信息Fi与第一频率阈值（Fmin）和第二频率阈值（Fmax）进行分析比较，在Fi小于Fmin时，则说明预设任务队列中的任务工作量在增加，进而可以确定当前处理任务的数量与所分配的CPU资源之间不匹配；在Fi大于Fmax时，则说明所分配的用于实现任务处理操作的CPU资源很多未被使用，进而可以确定当前处理任务的数量与所分配的CPU资源之间不匹配。在Fi大于或等于Fmin，且小于或等于Fmax时，则可以确定当前处理任务的数量与所分配的CPU资源相匹配。

另外，在排队时长为第二时长时，则说明此时的预设任务队列的队列状态为非空，此时的待处理任务的数量较多，进而可以确定当前处理任务的数量与所分配的CPU资源之间不匹配。

步骤23：基于检测结果对CPU资源进行调度操作。

如果检测结果为预设任务队列不为空，则说明此时预设任务队列中存在多个未处理的任务，为了能够提高任务处理的质量和效率，则可以为5G实例增加相对应的CPU资源，即为5G实例添加更多的CPU核，具体的，CPU核可以按照1个/次的方式进行增加。如果预设任务队列为空且有大量CPU资源未被使用，则可以减少分配给5G实例的CPU资源，但是减少后的CPU资源仍然能够保证任务的正常进行。

另外，在对CPU资源进行减少时，为了避免缩减后的CPU资源无法及时地应对下一时刻出现新增的多个待处理任务的情况，此时需要获取当前时刻与上一次进行CPU资源释放操作之间的时间间隔，若时间间隔大于或等于预设时长（可以为5us），则允许对CPU资源进行释放操作；若时间间隔小于预设时长，则禁止对CPU资源进行释放操作，这样可以在保证CPU资源利用率的同时，也能够保证任务处理的稳定运行。

此外，本应用实施例中的方法还能够实现对CPU资源的快速调度方法，一般情况下，5G流量在毫秒和微秒级都是突发的，而上述过程中的任务轮询操作能够在约1us进行一次，即可以实现在约1us进行CPU 核的分配操作，实现了资源的快速调度操作，由于越快速的调度，资源优化收益越高，具体的，可以通过以下技术来实现快读调度方法：

CPU核的随机选择：在对CPU 核进行重新分配的过程中，可以随机选择要添加或减少的CPU核；采用上述随机选择CPU核的策略原因是：目前，将5G实例中的工作线程移动到另一个物理CPU 核并不会导致额外的缓存未命中；这样根本原因是5G实例中的任务是运行至结束的，这意味着CPU 核的重新分配仅在工作线程完成其当前5G任务时发生。因此，即使工作线程被调度到同一个物理CPU 核上运行，由于工作线程加载了新的待处理任务，缓存也必须刷新。受此启发，随机选择CPU 核进行重新分配，因为无论在相同或不同的物理CPU 核上运行工作线程，缓存总是会刷新，这样可以避免产生额外的开销。

另外，由于消息传递是减缓资源调度操作的主要原因之一，即在捕获到任务轮询操作所产生的系统调用指令之后，资源调度装置可以相关信息从内核空间传递给运行在用户空间的主动调度器，由于消息通过内核进行传递，大约10us的延迟。为了解决上述技术问题，本应用实施例可以将每个单独的工作线程都配置有各自的共享内存，针对多个待调度任务而言，上述的多个待调度任务可以由多个工作线程来进行处理，而每个工作线程可以配置有各自独立的共享内存，这样对于多个工作线程而言，则会存在多个共享内存，这样可以避免因消息传递操作而降低数据处理的速度。

此外，在每个单独的工作线程所配置的共享内存中，可以维护有空信号计数器，该空信号计数器用于记录系统调用操作的时间戳，具体的，在数据每次走到工作流2时，则空信号计数器加1，通过空信号计数器可以获取到所有空信号计数器的历史值和当前值，基于当前值和历史值即可确定任务队列变空的频率信息，该频率信息能够用于进行资源调度操作，这样可以减少通信量并减轻调度程序在工作流分类中的工作量。

由于CPU读写数据的速度与访问的缓存行数有关，当不同的线程读取相同的缓存行时，也会触发额外的缓存失效，因此，为了进一步提高资源调度操作的速度，对于共享内存中的数据而言，可以按照缓存行对齐的方式进行读写操作，这样CPU可以以一个或多个缓存行的粒度从缓存中读取数据或写入数据，其中，每个缓存行通常为64字节，一个大小为m*64+n（n＜64）的数据会占用m+1个缓存行，在应用缓存行对齐后，资源调度装置的调度周期可以进一步减少10%。

当采用上述方式进行资源调度操作时，则具有以下优势：

高稳定性，能够保证5G软件较高的服务水平协议（SLA），通常大于99.9999%，这意味着5G实例每年的宕机时间不应超过30秒，并且，在进行资源调度操作时，任务处理的稳定性、质量和效果不降低。

透明度：不需要对5G软件更改源代码即可实现资源调度装置，该资源调度装置可以部署在云端，因此，资源调度装置相对于5G软件而言是透明的。

弹性：支持弹性工作负载，CPU资源的消耗需要匹配所服务的移动流量的增减，并且能够支持处理突发的移动流量，尤其是当流量很高时，另外，能够同时运行许多5G实例，每个实例都消耗与其流量相对应的CPU资源。

本应用实施例提供的技术方案，实现了RTC任务的安全调度、主动调度以及快速调度方案，这样能够在95%的情况下可以在1us内完成一轮CPU 核的重新分配操作，即使在流量非常大的情况下，在同一台服务器上同时运行多达8个5G实例，也不会超过4us，其中，上述的RTC的安全调度机制能够实现不打断5G RTC任务，有效保障5G软件运行的稳定性；具体的，通过捕获5G任务完成并释放其CPU 资源时生成的系统调用指令来进行CPU资源的调度操作；

其次，上述方案中的主动调度机制，能够实现无需改变5G软件代码，间接检测任务队列的长度，无代码入侵完成适配和调度，具体的，本实施例中的调度操作并不是在任务到达后分配CPU内核，而是主动分配CPU内核，通过间接探测任务队列的长度来完成；根据任务队列长度尝试分配足够的CPU核，以最小化任务队列中的任务数量；

最后，上述方案中的快速调度机制，为避免违反5G 任务期限，调度程序需要足够快以调度5G 任务，具体的，通过缓存、同步、数据结构等一系列优化技术，可以实现1us一次的超快速调度，能够在不修改5G RAN实例代码的前提下，适配现有的商用或开源5G系统。并且，能够以微秒级调度粒度支持多个5G RAN实例CPU资源共享，在有效优化CPU资源利用的同时保障5G系统的稳定性、时延、吞吐等指标，进一步提高了该方法的实用性，有利于市场的推广与应用。

参考附图14-图15所示，本实施例提供了一种车辆控制方法，该方法的执行主体为车辆控制装置，可以理解的是，该车辆控制装置可以实现为软件、或者软件和硬件的组合，具体的，在车辆控制装置实现为硬件时，其具体可以是具有车辆控制能力的各种电子设备。当车辆控制装置实现为软件时，其可以安装在上述所例举的电子设备中。具体的，该车辆控制方法可以包括：

步骤S1401：响应于对车辆控制任务的任务轮询操作，获取与任务轮询操作关联的系统调用指令；

步骤S1402：基于系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源；

步骤S1403：针对车辆控制任务，对空闲的系统计算资源进行资源调度操作，以通过基于所调度的系统计算资源对待控车辆进行控制。

具体的，在待控车辆（无人车或者有人车）行驶的过程中，待控车辆可以通过基站与车辆控制装置通信连接，为了能够实现对待控车辆进行准确有效地控制，车辆控制装置可以通过基站获取到一个或多个车辆控制任务，为了能够准确地车辆控制操作，可以对车辆控制任务的任务轮询操作，在对任务轮询操作的过程中，可以获取与任务轮询操作关联的系统调用指令，而后可以基于系统调用指令来确定空闲的系统计算资源，并对空闲的系统计算资源进行资源调度操作，以基于所调度的系统计算资源对待控车辆进行控制，具体的，可以基于所调度的系统计算资源生成与待控车辆相对应的控制信息，控制信息可以包括：车辆速度信息、车辆驾驶路径信息、车辆停车位信息等等，以基于控制信息对待控车辆进行稳定、有效地控制操作，例如，可以基于控制信息中的行驶路径的控制信息控制待控车辆所行驶的车道，即可以基于控制信息控制待控车辆由车道1切换至车道2。

在一些实例中，为了能够提高对车辆进行控制的稳定可靠性，待控车辆上可以设置有传感器，通过传感器可以快速获取与待控车辆相对应的运行状态数据，与待控车辆相对应的运行状态数据可以包括以下至少之一：车辆的当前车速、行驶方向和环境信息，其中，环境信息包括周围物体的分布位置、车辆前方车辆的车速和车辆所处道路的道路限速。在一些实例中，传感器可以包括图像采集传感器、雷达传感器和全球定位系统GPS，具体的，通过图像采集传感器、雷达传感器和全球定位系统GPS来确定与待控车辆相对应的运行状态数据。

需要注意的是，对于车辆控制装置而言，车辆控制装置可以设置于车辆上，或者，车辆控制装置可以独立于车辆进行设置，此时，车辆控制装置可以与车辆CPU通信连接。

另外，对于车辆控制装置而言，可以根据不同的车辆对车辆控制装置进行调整，即根据车辆类型的不同，车辆控制装置中所包括的算法模块也会有所不同，此时，车辆控制装置不仅可以实现车辆自动驾驶的控制操作，还可以实现的其他操作。例如，对于物流车辆、公共服务车辆、医疗服务车辆、终端服务车辆会涉及不同的车辆控制装置。下面分别针对这四种自动驾驶车辆对车辆控制装置中所包括的算法模块进行举例说明：

其中，物流车辆是指物流场景中使用的车辆，例如：可以是带自动分拣功能的物流车辆、带冷藏保温功能的物流车辆、带测量功能的物流车辆。这些物流车辆会涉及不同的算法模块。

例如，对于物流车辆，可以带有自动化的分拣装置，该分拣装置可以在物流车辆到达目的地后自动把货物取出并搬送、分拣、存放。这就涉及用于货物分拣的算法模块，该算法模块主要实现货物取出、搬运、分拣以及存放等逻辑控制。

又例如，针对冷链物流场景，物流车辆还可以带有冷藏保温装置，该冷藏保温装置可以实现运输的水果、蔬菜、水产品、冷冻食品以及其它易腐烂的食品进行冷藏或保温，使之处于合适的温度环境，解决易腐烂食品的长途运输问题。这就涉及用于冷藏保温控制的算法模块，该算法模块主要用于根据食品（或物品）性质、易腐性、运输时间、当前季节、气候等信息动态、自适应计算冷餐或保温的合适温度，根据该合适温度对冷藏保温装置进行自动调节，这样在车辆运输不同食品或物品时运输人员无需手动调整温度，将运输人员从繁琐的温度调控中解放出来，提高冷藏保温运输的效率。

又例如，在大多物流场景中，是根据包裹体积和/或重量进行收费的，而物流包裹的数量非常庞大，单纯依靠快递员对包裹体积和/或重量进行测量，效率非常低，人工成本较高。因此，在一些物流车辆中，增设了测量装置，可自动测量物流包裹的体积和/或重量，并计算物流包裹的费用。这就涉及用于物流包裹测量的算法模块，该算法模块主要用于识别物流包裹的类型，确定物流包裹的测量方式，如进行体积测量还是重量测量或者是同时进行体积和重量的组合测量，并可根据确定的测量方式完成体积和/或重量的测量，以及根据测量结果完成费用计算。

其中，公共服务车辆是指提供某种公共服务的车辆，例如：可以是消防车、除冰车、洒水车、铲雪车、垃圾处理车辆、交通指挥车辆等。这些公共服务车辆会涉及不同算法模块。

例如，对于自动驾驶的消防车，其主要任务是针对火灾现场进行合理的灭火任务，这就涉及用于灭火任务的算法模块，该算法模块至少需要实现火灾状况的识别、灭火方案的规划以及对灭火装置的自动控制等逻辑。

又例如，对于除冰车，其主要任务是清除路面上结的冰雪，这就涉及除冰的算法模块，该算法模块至少需要实现路面上冰雪状况的识别、根据冰雪状况制定除冰方案，如哪些路段需要采取除冰，哪些路段无需除冰，是否采用撒盐方式、撒盐克数等，以及在确定除冰方案的情况下对除冰装置的自动控制等逻辑。

其中，医疗服务车辆是指能够提供一种或多种医疗服务的自动驾驶车辆，该种车辆可提供消毒、测温、配药、隔离等医疗服务，这就涉及提供各种自助医疗服务的算法模块，这些算法模块主要实现消毒需求的识别以及对消毒装置的控制，以使消毒装置为病人进行消毒，或者对病人位置的识别，控制测温装置自动贴近病人额头等位置为病人进行测温，或者，用于实现对病症的判断，根据判断结果给出药方并需要实现对药品/药品容器的识别，以及对取药机械手的控制，使之按药方为病人抓取药品，等等。

其中，终端服务车辆是指可代替一些终端设备面向用户提供某种便利服务的自助型的自动驾驶车辆，例如这些车辆可以为用户提供打印、考勤、扫描、开锁、支付、零售等服务。

例如，在一些应用场景中，用户经常需要到特定位置去打印或扫描文档，费时费力。于是，出现一种可以为用户提供打印/扫描服务的终端服务车辆，这些服务车辆可以与用户终端设备互联，用户通过终端设备发出打印指令，服务车辆响应打印指令，自动打印用户所需的文档并可自动将打印出的文档送至用户位置，用户无需去打印机处排队，可极大地提高打印效率。或者，可以响应用户通过终端设备发出的扫描指令，移动至用户位置，用户将待扫描的文档放置的服务车辆的扫描工具上完成扫描，无需到打印/扫描机处排队，省时省力。这就涉及提供打印/扫描服务的算法模块，该算法模块至少需要识别与用户终端设备的互联、打印/扫描指令的响应、用户位置的定位以及行进控制等。

又例如，随着新零售场景的开展，越来越多的电商借助于自助售货机将商品销售送到了各大办公楼、公共区，但这些自助售货机被放置在固定位置，不可移动，用户需要到该自助售货机跟前才能购买所需商品，便利性还是较差。于是出现了可提供零售服务的自助驾驶车辆，这些服务车辆可以承载商品自动移动，并可提供对应的自助购物类APP或购物入口，用户借助于手机等终端通过APP或购物入口可以向提供零售服务的自动驾驶车辆进行下单，该订单中包括待购买的商品名称、数量以及用户位置，该车辆收到下单请求之后，可以确定当前剩余商品是否具有用户购买的商品以及数量是否足够，在确定具有用户购买的商品且数量足够的情况下，可携带这些商品自动移动至用户位置，将这些商品提供给用户，进一步提高用户购物的便利性，节约用户时间，让用户将时间用于更为重要的事情上。这就涉及提供零售服务的算法模块，这些算法模块主要实现响应用户下单请求、订单处理、商品信息维护、用户位置定位、支付管理等逻辑。

需要注意的是，本实施例中的方法还可以包括图4-图13所示实施例中的方法，本实施例未详细描述的部分，可参考对图4-图13所示实施例的相关说明。该技术方案的执行过程和技术效果参见图4-图13所示实施例中的描述，在此不再赘述。

参考附图16所示，本实施例提供了一种虚拟现实设备的控制方法，该方法的执行主体为虚拟现实设备的控制装置，可以理解的是，该虚拟现实设备的控制装置可以实现为软件、或者软件和硬件的组合，具体的，在虚拟现实设备的控制装置实现为硬件时，其具体可以是具有虚拟现实设备的控制操作的各种电子设备。当虚拟现实设备的控制装置实现为软件时，其可以安装在上述所例举的电子设备中。该虚拟现实设备的控制方法包括：

步骤S1601：响应于对虚拟现实设备控制任务的任务轮询操作，获取与任务轮询操作关联的系统调用指令；

步骤S1602：基于系统调用指令，确定用于实现任务处理操作的多个空闲的系统计算资源；

步骤S1603：针对虚拟现实设备控制任务，对多个空闲的系统计算资源进行资源调度操作，以通过基于所调度的系统计算资源对虚拟现实设备进行控制。

需要注意的是，本实施例中的方法还可以包括图4-图13所示实施例中的方法，本实施例未详细描述的部分，可参考对图4-图13所示实施例的相关说明。该技术方案的执行过程和技术效果参见图4-图13所示实施例中的描述，在此不再赘述。

参考附图17所示，本实施例提供了一种资源调度装置，该资源调度装置可以包括：

第一获取模块11，用于获取与任务轮询操作关联的系统调用指令；

第一确定模块12，用于基于系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源；

第一处理模块13，用于对空闲的系统计算资源进行资源调度操作。

在一些实例中，在第一确定模块12基于系统调用指令，确定用于实现任务处理操作的多个空闲的系统计算资源时，该第一确定模块12用于执行：基于系统调用指令，确定待处理任务的任务完成时间；基于任务完成时间，确定用于实现任务处理操作的多个空闲的系统计算资源。

在一些实例中，在第一确定模块12基于系统调用指令，确定待处理任务的任务完成时间时，该第一确定模块12用于执行：获取与系统调用指令相对应的时间戳信息，时间戳信息用于标识进入系统调度操作的时间；基于时间戳信息，确定待处理任务的任务完成时间。

在一些实例中，在第一确定模块12基于任务完成时间，确定用于实现任务处理操作的多个空闲的系统计算资源时，该第一确定模块12用于执行：获取待处理任务所对应的占用系统计算资源；基于任务完成时间对占用系统计算资源进行释放，获得释放系统计算资源；将释放系统计算资源和其他空闲的系统计算资源，确定为用于实现任务处理操作的多个空闲的CPU资源。

在一些实例中，本实施例中的第一处理模块13用于执行：检测当前处理任务的数量与所分配的系统计算资源之间是否匹配；在当前处理任务的数量与系统计算资源之间相匹配时，则保持对系统计算资源的分配状态；在当前处理任务的数量与系统计算资源之间不匹配时，则对当前处理任务与系统计算资源进行重分配操作。

在一些实例中，在第一处理模块13检测当前处理任务的数量与所分配的系统计算资源之间是否匹配时，该第一处理模块13用于执行：获取当前处理任务在预设任务队列中的排队时长；基于排队时长，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配。

在一些实例中，在第一处理模块13获取当前处理任务在预设任务队列中的排队时长时，该第一处理模块13用于执行：获取当前处理任务所对应的预设任务队列的队列状态；在队列状态为空时，则确定排队时长为用于标识队列状态为空的第一时长；在队列状态为非空时，则确定排队时长为用于标识队列状态为非空的第二时长；其中，第一时长和第二时长均为二进制信息。

在一些实例中，在第一处理模块13获取当前处理任务所对应的预设任务队列的队列状态时，该第一处理模块13用于执行：获取当前处理任务所对应的两次连续的系统调用指令；确定两次连续的系统调用指令之间的时间间隔；基于时间间隔，确定当前处理任务所对应的预设任务队列的队列状态。

在一些实例中，在第一处理模块13基于时间间隔，确定当前处理任务所对应的预设任务队列的队列状态时，该第一处理模块13用于执行：在时间间隔大于第一间隔阈值时，则确定队列状态为非空；在时间间隔小于第二间隔阈值时，则确定队列状态为空，其中，第二间隔阈值小于第一间隔阈值。

在一些实例中，在第一处理模块13获取当前处理任务所对应的预设任务队列的队列状态时，该第一处理模块13用于执行：获取当前处理任务所对应的计算资源运行周期；基于计算资源运行周期，确定当前处理任务所对应的预设任务队列的队列状态。

在一些实例中，在第一处理模块13基于计算资源运行周期，确定当前处理任务所对应的预设任务队列的队列状态时，该第一处理模块13用于执行：在计算资源运行周期大于第一周期阈值时，则确定队列状态为非空；在计算资源运行周期小于第二周期阈值时，则确定队列状态为空，其中，第二周期阈值小于第一周期阈值。

在一些实例中，在第一处理模块13基于排队时长，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配时，该第一处理模块13用于执行：在排队时长为第一时长时，则获取预设任务队列变空的频率信息；基于频率信息，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配。

在一些实例中，在第一处理模块13基于频率信息，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配时，该第一处理模块13用于执行：在频率信息小于或等于第一频率阈值时，则确定当前处理任务的数量与所分配的系统计算资源不匹配，并新增用于处理当前处理任务的系统计算资源；在频率信息大于第二频率阈值时，则获取与上一次进行系统计算资源释放操作的时间间隔，基于时间间隔检测当前处理任务的数量与所分配的系统计算资源之间是否匹配；其中，第二频率阈值大于第一频率阈值。在频率信息大于第一频率阈值、且小于或等于第二频率阈值时，则确定当前处理任务的数量与所分配的系统计算资源相匹配。

在一些实例中，在第一处理模块13基于时间间隔检测当前处理任务的数量与所分配的系统计算资源之间是否匹配时，该第一处理模块13用于执行：在时间间隔大于预设时长阈值时，则确定当前处理任务的数量与所分配的系统计算资源不匹配，并对与当前处理任务相对应的部分空闲系统计算资源进行释放；在时间间隔小于或等于预设时长阈值时，则确定当前处理任务的数量与所分配的系统计算资源相匹配，并保持当前处理任务与系统计算资源之间的分配关系。

在一些实例中，在第一处理模块13获取预设任务队列变空的频率信息时，该第一处理模块13用于执行：获取与预设任务队列相对应的所有任务线程；确定所有任务线程各自对应的内存空间，内存空间配置有空信号计数器，其中，不同的任务线程所对应的内存空间相互独立；基于所有的任务线程对应的所有空信号计数器，确定预设任务队列变空的频率信息。

图17所示资源调度装置可以执行图6-图13所示实施例的方法，本实施例未详细描述的部分，可参考对图6-图13所示实施例的相关说明。该技术方案的执行过程和技术效果参见图6-图13所示实施例中的描述，在此不再赘述。

在一个可能的设计中，图17所示资源调度装置的结构可实现为一电子设备。参考附图18所示，本实施例中的资源调度装置可以实现为一电子设备，具体的，该电子设备可以包括：第一处理器21和第一存储器22。其中，第一存储器22用于存储相对应电子设备执行上述图6所示实施例中提供的资源调度方法的程序，第一处理器21被配置为用于执行第一存储器22中存储的程序。

程序包括一条或多条计算机指令，其中，一条或多条计算机指令被第一处理器21执行时能够实现如下步骤：获取与任务轮询操作关联的系统调用指令；基于系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源；对空闲的系统计算资源进行资源调度操作。

进一步的，第一处理器21还用于执行前述图6所示实施例中的全部或部分步骤。其中，电子设备的结构中还可以包括第一通信接口23，用于电子设备与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机存储介质，用于储存电子设备所用的计算机软件指令，其包含用于执行上述图6所示方法实施例中的资源调度方法所涉及的程序。

此外，本发明实施例提供了一种计算机程序产品，包括：计算机程序，当计算机程序被电子设备的处理器执行时，使处理器执行图6所示方法实施例中的资源调度方法。

参考附图19所示，本实施例提供了一种车辆控制装置，该车辆控制装置可以包括：

第二获取模块31，用于响应于对车辆控制任务的任务轮询操作，获取与任务轮询操作关联的系统调用指令；

第二确定模块32，用于基于系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源；

第二处理模块33，用于针对车辆控制任务，对空闲的系统计算资源进行资源调度操作，以基于所调度的系统计算资源对待控车辆进行控制。

图19所示车辆控制装置可以执行图15所示实施例的方法，本实施例未详细描述的部分，可参考对图15所示实施例的相关说明。该技术方案的执行过程和技术效果参见图15所示实施例中的描述，在此不再赘述。

在一个可能的设计中，图19所示车辆控制装置的结构可实现为一电子设备。参考附图20所示，本实施例中的用于实现车辆控制方法的车辆控制装置可以实现为一电子设备，具体的，该电子设备可以包括：第二处理器41和第二存储器42。其中，第二存储器42用于存储相对应电子设备执行上述图15所示实施例中提供的车辆控制方法的程序，第二处理器41被配置为用于执行第二存储器42中存储的程序。

程序包括一条或多条计算机指令，其中，一条或多条计算机指令被第二处理器41执行时能够实现如下步骤：响应于对车辆控制任务的任务轮询操作，获取与任务轮询操作关联的系统调用指令；基于系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源；针对车辆控制任务，对空闲的系统计算资源进行资源调度操作，以基于所调度的系统计算资源对待控车辆进行控制。

进一步的，第二处理器41还用于执行前述图15所示实施例中的全部或部分步骤。其中，电子设备的结构中还可以包括第二通信接口43，用于电子设备与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机存储介质，用于储存电子设备所用的计算机软件指令，其包含用于执行上述图15所示方法实施例中的车辆控制方法所涉及的程序。

此外，本发明实施例提供了一种计算机程序产品，包括：计算机程序，当计算机程序被电子设备的处理器执行时，使处理器执行图15所示方法实施例中的车辆控制方法。

参考附图21所示，本实施例提供了一种虚拟现实设备的控制装置，包括：

第三获取模块51，用于响应于对虚拟现实设备控制任务的任务轮询操作，获取与任务轮询操作关联的系统调用指令；

第三确定模块52，用于基于系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源；

第三处理模块53，用于针对虚拟现实设备控制任务，对空闲的系统计算资源进行资源调度操作，以基于所调度的系统计算资源对虚拟现实设备进行控制。

图21所示虚拟现实设备的控制装置可以执行图16所示实施例的方法，本实施例未详细描述的部分，可参考对图16所示实施例的相关说明。该技术方案的执行过程和技术效果参见图16所示实施例中的描述，在此不再赘述。

在一个可能的设计中，图21所示虚拟现实设备的控制装置的结构可实现为一电子设备。参考附图22所示，本实施例中的用于虚拟现实设备的控制方法的虚拟现实设备的控制装置可以实现为一电子设备，具体的，该电子设备可以包括：第三处理器61和第三存储器62。其中，第三存储器62用于存储相对应电子设备执行上述图16所示实施例中提供的虚拟现实设备的控制方法的程序，第三处理器61被配置为用于执行第三存储器62中存储的程序。

程序包括一条或多条计算机指令，其中，一条或多条计算机指令被第三处理器61执行时能够实现如下步骤：响应于对虚拟现实设备控制任务的任务轮询操作，获取与任务轮询操作关联的系统调用指令；基于系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源；针对虚拟现实设备控制任务，对空闲的系统计算资源进行资源调度操作，以基于所调度的系统计算资源对虚拟现实设备进行控制。

进一步的，第三处理器61还用于执行前述图16所示实施例中的全部或部分步骤。其中，电子设备的结构中还可以包括第三通信接口63，用于电子设备与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机存储介质，用于储存电子设备所用的计算机软件指令，其包含用于执行上述图16所示方法实施例中的虚拟现实设备的控制方法所涉及的程序。

此外，本发明实施例提供了一种计算机程序产品，包括：计算机程序，当计算机程序被电子设备的处理器执行时，使处理器执行图16所示方法实施例中的虚拟现实设备的控制方法。

参考附图23所示，本实施例提供了一种资源调度方法，该资源调用方法的执行主体可以为专网的资源调度云平台，即资源调度方法应用于专网的资源调度云平台，本实施例中的方法可以包括：

步骤S2301：获取与任务轮询操作关联的系统调用指令。

步骤S2302：基于所述系统调用指令，确定用于实现任务处理操作的空闲的云计算资源。

步骤S2303：对空闲的云计算资源进行资源调度操作。

在一些实例中，基于所述系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源可以包括：基于系统调用指令，确定待处理任务的任务完成时间；基于所述任务完成时间，确定用于实现任务处理操作的空闲的云计算资源。

其中，在专网的应用场景中，可以部署有资源调度云平台，该资源调度云平台可以部署在云网络中，并且，资源调度云平台可以通信连接有预设专网中的一个或多个专网设备，这样通过资源调度云平台可以在利用专网设备进行数据处理的过程中，对空闲的云计算资源进行资源调度操作，具体的，本实施中上述步骤的具体实现方式和实现效果与上述图6-图13所对应实施例的具体实现方式和实现效果相类似，具体可参考上述陈述内容，在此不再赘述。

参考附图24所示，本实施例提供了一种专网的资源调度云平台，该专网的资源调度云平台用于执行上述图23所示的资源调度方法，具体的，该专网的资源调度云平台可以包括：

第四获取模块71，用于获取与任务轮询操作关联的系统调用指令。

第四确定模块72，用于基于所述系统调用指令，确定用于实现任务处理操作的空闲的云计算资源。

第四处理模块73，用于对空闲的云计算资源进行资源调度操作。

图24所示专网的资源调度云平台可以执行图23所示实施例的方法，本实施例未详细描述的部分，可参考对图23所示实施例的相关说明。该技术方案的执行过程和技术效果参见图23所示实施例中的描述，在此不再赘述。

在一个可能的设计中，图24所示专网的资源调度云平台的结构可实现为一电子设备。参考附图25所示，本实施例中的专网的资源调度云平台可以部署在专网云上，具体的，该电子设备可以包括：第四处理器81和第四存储器82。其中，第四存储器82用于存储相对应电子设备执行上述图23所示实施例中提供的资源调度方法的程序，第四处理器81被配置为用于执行第四存储器82中存储的程序。

程序包括一条或多条计算机指令，其中，一条或多条计算机指令被第三处理器61执行时能够实现如下步骤：获取与任务轮询操作关联的系统调用指令，基于所述系统调用指令，确定用于实现任务处理操作的空闲的云计算资源，对空闲的云计算资源进行资源调度操作。

进一步的，第四处理器81还用于执行前述图23所示实施例中的全部或部分步骤。其中，电子设备的结构中还可以包括第四通信接口83，用于电子设备与其他设备或通信网络通信。

另外，本发明实施例提供了一种计算机存储介质，用于储存电子设备所用的计算机软件指令，其包含用于执行上述图23所示方法实施例中的资源调度方法所涉及的程序。

此外，本发明实施例提供了一种计算机程序产品，包括：计算机程序，当计算机程序被电子设备的处理器执行时，使处理器执行图23所示方法实施例中的资源调度方法。

需要说明的是，本申请所涉及的用户信息（包括但不限于用户设备信息、用户个人信息等）和数据（包括但不限于用于分析的数据、存储的数据、展示的数据等），均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程设备的处理器以产生一个机器，使得通过计算机或其他可编程设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器 (CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM) 和/或非易失性内存等形式，如只读存储器 (ROM) 或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现数据存储。数据可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (PRAM)、静态随机存取存储器 (SRAM)、动态随机存取存储器 (DRAM)、其他类型的随机存取存储器 (RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘 (DVD) 或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的数据。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体 (transitory media)，如调制的数据信号和载波。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (12)

1.一种资源调度方法，其特征在于，包括：

获取与任务轮询操作关联的系统调用指令；

基于所述系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源；

对空闲的系统计算资源进行资源调度操作。

2.根据权利要求1所述的方法，其特征在于，基于所述系统调用指令，确定用于实现任务处理操作的空闲的系统计算资源，包括：

基于所述系统调用指令，确定待处理任务的任务完成时间；

基于所述任务完成时间，确定用于实现任务处理操作的空闲的系统计算资源。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

检测当前处理任务的数量与所分配的系统计算资源之间是否匹配；

在所述当前处理任务的数量与所述系统计算资源之间相匹配时，则保持对所述系统计算资源的分配状态；

在所述当前处理任务的数量与所述系统计算资源之间不匹配时，则对所述当前处理任务与所述系统计算资源进行重分配操作。

4.根据权利要求3所述的方法，其特征在于，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配，包括：

获取所述当前处理任务在预设任务队列中的排队时长；

基于所述排队时长，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配。

5.根据权利要求4所述的方法，其特征在于，获取所述当前处理任务在预设任务队列中的排队时长，包括：

获取所述当前处理任务所对应的预设任务队列的队列状态；

在所述队列状态为空时，则确定所述排队时长为用于标识所述队列状态为空的第一时长；

在所述队列状态为非空时，则确定所述排队时长为用于标识所述队列状态为非空的第二时长；其中，所述第一时长和第二时长均为二进制信息。

6.根据权利要求5所述的方法，其特征在于，获取所述当前处理任务所对应的预设任务队列的队列状态，包括：

获取所述当前处理任务所对应的两次连续的系统调用指令；

确定两次连续的系统调用指令之间的时间间隔；

基于所述时间间隔，确定所述当前处理任务所对应的预设任务队列的队列状态。

7.根据权利要求5所述的方法，其特征在于，获取所述当前处理任务所对应的预设任务队列的队列状态，包括：

获取所述当前处理任务所对应的计算资源运行周期；

基于所述计算资源运行周期，确定所述当前处理任务所对应的预设任务队列的队列状态。

8.根据权利要求4所述的方法，其特征在于，基于所述排队时长，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配，包括：

在所述排队时长为第一时长时，则获取所述预设任务队列变空的频率信息；

基于所述频率信息，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配。

9.根据权利要求8所述的方法，其特征在于，基于所述频率信息，检测当前处理任务的数量与所分配的系统计算资源之间是否匹配，包括：

在所述频率信息小于或等于第一频率阈值时，则确定当前处理任务的数量与所分配的系统计算资源不匹配；

在所述频率信息大于第二频率阈值时，则获取与上一次进行系统计算资源释放操作的时间间隔，基于所述时间间隔检测当前处理任务的数量与所分配的系统计算资源之间是否匹配；其中，所述第二频率阈值大于第一频率阈值；

在所述频率信息大于第一频率阈值、且小于或等于第二频率阈值时，则确定当前处理任务的数量与所分配的系统计算资源相匹配。

10.根据权利要求9所述的方法，其特征在于，基于所述时间间隔检测当前处理任务的数量与所分配的系统计算资源之间是否匹配，包括：

在所述时间间隔大于预设时长阈值时，则确定当前处理任务的数量与所分配的系统计算资源不匹配；

在所述时间间隔小于或等于预设时长阈值时，则确定当前处理任务的数量与所分配的系统计算资源相匹配。

11.一种资源调度方法，其特征在于，应用于专网的资源调度云平台，所述方法包括：

获取与任务轮询操作关联的系统调用指令；

基于所述系统调用指令，确定用于实现任务处理操作的空闲的云计算资源；

对空闲的云计算资源进行资源调度操作。

12.一种电子设备，其特征在于，包括：存储器、处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行时实现如权利要求1-11中任意一项所述的方法。

Images