CN114840318A - 一种多进程抢占硬件key加解密资源的调度方法 - Google Patents
一种多进程抢占硬件key加解密资源的调度方法 Download PDFInfo
- Publication number
- CN114840318A CN114840318A CN202210453521.7A CN202210453521A CN114840318A CN 114840318 A CN114840318 A CN 114840318A CN 202210453521 A CN202210453521 A CN 202210453521A CN 114840318 A CN114840318 A CN 114840318A
- Authority
- CN
- China
- Prior art keywords
- decryption
- encryption
- task
- file
- hardware key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5011—Pool
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5021—Priority
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2107—File encryption
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Storage Device Security (AREA)
Abstract
本发明提供一种多进程抢占硬件key加解密资源的调度方法,调度方法包括如下步骤:步骤1、启动文件加解密服务,自动创建性能状态线程池;步骤2、硬件key等待加解密任务的提交,并定义文件加解密优先级,按优先等级进行加解密任务;步骤3、侦测是否有电话或者进行录像,暂停加解密任务,任务可继续提交;步骤4、释放硬件key资源,丢弃正在加解密的文件;步骤5、等电话或者进行录像完成后,继续文件加解密任务。本发明的有益效果在于:保证在文件加解密的过程中同时能进行其他的任务,提高文件加解密效率,保证***的正常运行;对于批量处理文件加解密的任务,创建了线程池,根据任务优先级分配硬件资源,一方面减少内存消耗,另一方面便于***资源管理。
Description
技术领域
本发明涉及信息安全技术领域,特别是一种多进程抢占硬件key加解密资源的调度方法。
背景技术
随着信息技术和智能终端的快速发展,人们生活和工作越来越离不开智能终端,数据加密技术也越来越成熟,越来越多的加密软件和硬件设备出现。随着人们使用智能终端越来越频繁,智能终端存储着大量的重要文件,这些文件需要被加解密,在文件加解密的过程中,需要涉及到对硬件key资源的调度和使用,为了更好地利用硬件key资源进行多进程任务的操作,现有技术通常进行多任务的并发运行,确保应用在同一时刻内可以进行多进程的加解密任务,提高文件加解密效率。
现有的技术中,针对硬件设备的调用通常是用单个加密芯片硬件资源被终端机器的多应用、多进程调用,导致硬件资源存在效率低、资源抢占等问题,从而致使硬件状态混乱、加解密数据在芯片内无进程隔离导致数据计算混乱、加解密失败等现象,甚至导致智能终端运行卡顿。
目前终端机器使用单个硬件资源针对多应用、多进程调用硬件资源存在效率低、资源抢占等问题,容易导致硬件状态混乱、加解密数据在芯片内无进程隔离导致数据计算混乱、加解密失败等现象。
发明内容
根据现有技术的缺陷,本发明构建一个任务调度中心,在应用之间设置进程的调度方法并在文件加解密过程中设置线程池,设计任务级别优先级,根据进程任务的优先级,将任务优先级高的优先占用硬件资源进行处理,平级的根据任务提交顺序进行依次加解密,保证任务有序地进行,避免拥堵和崩溃,大大提高文件加解密效率,保证硬件资源的最大化使用。是通过如下技术方案实现的。
一种多进程抢占硬件key加解密资源的调度方法,包括如下步骤:
步骤1、启动文件加解密服务,自动创建性能状态线程池;
步骤2、硬件key等待加解密任务的提交,并定义文件加解密优先级,按优先等级进行加解密任务;
步骤3、侦测是否有电话或者进行录像等业务数据,暂停加解密任务,任务可继续提交;
步骤4、释放硬件key资源,丢弃正在加解密的文件;
步骤5、等电话或者进行录像等业务数据完成后,继续文件加解密任务。
本发明的有益效果是:本专利发明针对用户终端在多应用、多进程状态下调用硬件设备资源存在效率低下、资源抢占导致***崩溃、加解密失败以及存储数据无法进行安全隔离等情况,做出了优化,在不同情景下,根据不同的需求,合理的分配硬件设备资源,保证在文件加解密的过程中同时能进行其他的任务,提高文件加解密效率,保证***的正常运行。
附图说明
图1是一种多进程抢占硬件key加解密资源的调度方法的加密***结构图。
图2是一种多进程抢占硬件key加解密资源的调度方法的硬件key资源多进程处理流程图。
图3是一种多进程抢占硬件key加解密资源的调度方法的文件加解流程图。
图4是一种多进程抢占硬件key加解密资源的调度方法的硬件key资源功能结构示意图。
图5是一种多进程抢占硬件key加解密资源的调度方法的硬件资源多进程调度池关系示意图。
图6是一种多进程抢占硬件key加解密资源的调度方法的进程处理流程图。
具体实施方式
以下结合附图对本发明的实施例进行详细说明,但是本发明可以由权利要求限定和覆盖的多种不同方式实施。
如图1、2、4、5所示,图1是一种多进程抢占硬件key加解密资源的调度方法的加密***流程图,图2是一种多进程抢占硬件key加解密资源的调度方法的硬件key资源多进程处理流程图,图4是一种多进程抢占硬件key加解密资源的调度方法的进程处理示意图,图5是一种多进程抢占硬件key加解密资源的调度方法的硬件资源多进程调度池关系示意图。
如图1所示,一种加解密***,***内设置了各个与加解密相关的应用,当这些应用启动时,会涉及应用与硬件key的基本通信和密钥交换,所述硬件key包括全局监听模块、加解密调度模块以及资源控制模块,其中:
其中全局监听模块主要监听加解密***的各类事件进程,包括文件加解密任务、通话、信息、拍照和录像等任务。
加解密调度模块为硬件key与消息队列中的任务分配硬件资源的处理器,在有文件加解密任务时,硬件key根据***性能生成状态线程池,按加解密任务的优先级进行任务加解密。当有通话、消息、拍照、录像等业务数据的进程发生并送到消息队列中时,便会介入文件加解密任务的执行,加解密调度中心会将硬件资源优先调度给通话、信息、拍照和录像等业务数据的外部进程使用,并暂停文件加解密的处理。待外部事件处理完成,加解密调度中心再将硬件资源交还给在队列中的文件加解密任务,继续进行文件的加解密任务。
如图5所示,加解密***内设置了各个与加解密相关的业务,当这些业务串行时,会涉及应用与硬件key的基本通信和密钥交换,通过硬件key设置调度中心,所述调度中心,配置一个业务调度池,所述业务调度池通过硬件key返回状态进行判断然后调度,当目前硬件状态为空闲态时,从业务优先队列中获取到最高业务进程并执行;当目前硬件key状态为占用态时,根据硬件key返回特殊码,执行对应进程。
如图2所示,当硬件状态为占用态时,根据硬件返回特殊码,硬件key设置安全域环境并设定了一个业务的指令集执行顺序,具体分类如下:
第一类:执行耗时较久的指令过程,如密钥对生成、导入密钥。硬件key返回第一特殊码,让多线程执行一些耗时的任务、IO(Input/Output)收发、资源释放、性能调整。
第二类:安全域环境初始化:init(初始化)类的指令,硬件key返回第二特殊码,调度中心执行同进程的安全域环境下的剩余指令,除此之外的进程和同进程其他指令都不进行调度处理。
第三类:组合指令结束,但安全域环境未结束:update类的指令,或者HASH+签名验签的配合指令,此时代表有业务是连续性的。硬件key返回第三特殊码,调度就要把同进程的指令优先级调高。
第四类:安全域环境结束:代表该线程的任务马上结束。硬件key返回第四特殊码,调度中心就停止优先队列的调整工作,获取优先级最高的任务指令,并从数据集合中把对应的源数据调出来,准备新业务开始。
根据硬件特殊码所对应的安全域环境种类,执行对应的操作。
资源控制中心主要负责任务的执行、暂停和恢复,使多进程有序使用硬件资源,提高硬件资源利用率,保证加密业务高效顺利进行,提高用户使用体验。
加解密***内设置了各个与加解密相关的业务,包括硬件计算、硬件加密、硬件加密等,当这些业务串行时,会涉及应用与硬件key的基本通信和密钥交换等。当单一业务进程进行加解密的时候,并不会设计对硬件key资源的抢占,当这些业务串行时,则会涉及对硬件资源的抢占,为了保证能够顺利地完成这些任务,硬件key设置调度中心,设置了安全域环境并设定了一个业务的指令集执行顺序,为多进程业务进行资源的合理分配。
当有多个进程需要使用硬件资源时,就涉及到硬件资源的调度问题,本发明设置一个硬件资源调度器,对外是调度池,对内,硬件根据调度及业务处理,将业务数据处理、业务数据返回、业务操作状态进行了多进程的设计。业务调度池通过硬件返回状态进行判断然后调度,硬件资源的使用状态具体有空闲态和占用态。当目前硬件状态为空闲态时,从业务优先队列中获取到最高业务进程并执行;当目前硬件key状态为占用态时,根据硬件返回特殊码,根据规则执行对应进程,具体过程如图4。已完成的业务会返回完成状态和数据。
本发明基于硬件设备,对终端应用程序运行机制的进程管理、内存管理和手机***资源管理的再度组合优化,保证加解密任务能够及时完成的同时,也能保证其他应用能够正常使用硬件资源,保证***的正常运行。
如图3是一种多进程抢占硬件key加解密资源的调度方法的流程图,涉及一种加解密资源的调度方法,包括如下步骤:
步骤1、启动文件加解密服务,自动创建性能状态线程池;
步骤2、硬件key等待加解密任务的提交,并定义文件加解密优先级,按优先等级进行加解密任务;
步骤3、侦测是否有电话或者进行录像,暂停加解密任务,任务可继续提交;
步骤4、释放硬件key资源,丢弃正在加解密的文件;
步骤5、等电话或者进行录像完成后,继续文件加解密任务。
当文件加解密服务启动后,***首先会创建一个线程数量为1的线程池,用来运行加解密任务和文件处理的IO读写以及加解密任务的运行状态的管理,如进度、结果状态、错误信息等,然后对外暴露加密解密请求接口,和任务处理状态的接口,供其他进程进行加解密的请求和状态访问,等待加解密文件的提交。硬件key定义了文件加解密状态的优先级,以文件的优先级来分配硬件key的资源调度,优先级相同的以提交的顺序进行加解密资源的分配。硬件key会监听加解密***全局的资源调度,当有电话、聊天、拍照或者录像等业务数据时,硬件key的资源控制中心会暂停文件加解密任务,但任务可以继续提交并在队列中等待,一直到文件线程池满载为止。已经被文件加解密任务抢占的硬件key资源会主动释放,并丢弃正在加解密的文件,当通话、聊天、拍照和录像完成后,文件加解密任务会立即恢复原有状态,继续进行文件加解密任务。
如图5是一种多进程抢占硬件key加解密资源的调度方法的文件加解密线程池关系图。硬件key将业务数据处理、业务返回数据、业务操作状态进行了多进程调度的设计,设置一个硬件key的资源调度池,其中的功能包括并发数量的控制、文件加解密状态的感知、资源抢占的暂停与恢复以及文件加解密处理结果全局通知等。
其中并发数量的控制保证硬件key在同一时间进程任务数量的控制,保证***在能承受的最大阈值内平稳地运行,维持稳定的加解密***环境。
文件加解密状态的感知功能主要用于判断加解密***是否在执行、暂停以及恢复加解密任务,对于文件加解密任务的执行感知主要为了创建文件加解密任务的线程池,从而方便管理线程,减少对硬件资源的消耗。文件加解密任务的暂停与恢复的感知主要用于判断在执行通话和信息等过程中或者结束后,保证文件加解密任务的暂停和恢复。
资源抢占的暂停与恢复功能主要用于在执行通话或者拍摄过程中对文件加解密任务的暂停与恢复。文件加解密处理结果全局通知功能用于对加解密***各种应用***执行前的判断,一则保证加解密任务的顺利进行,二则保证多进程任务的能够并发运行,保证***不崩溃。
如图6是一种多进程抢占硬件key加解密资源的调度方法的进程处理流程图,包括如下步骤:
第一步,当有文件和通话拍照等多个任务同时要进行加解密时,发送请求到通信接口,通信接口是资源调度内部工作状态和上层业务逻辑交互的通信桥梁。
通信接口主要功能有:1)负责维护上层业务所有的资源请求、状态保存、以及数据传递;2)将内部加解密任务状态、错误信息、以及各种请求响应回传给上层业务;3)对外部资源请求进行检测,是否是有效请求,以及是保存还是丢弃等进行初期的请求决策;4)资源调度运行内核的运行状态以及生命周期和资源分配情况定时上报给外部交互。
在本发明的具体实施例中,通信结构的具体工作如下:当上层业务需要请求加解密时,首先将请求信息打包封装成消息对象,发送到通信接口,通信接口,通信接口对请求信息进行解析、判断是否是有效请求。
如果是有效请求,则保存关键信息参数,然后传递给内部请求队列,如果是无效请求,则直接丢弃并接返回。提交成功的请求,通信接口还会携带当前任务的执行状态(正在执行、执行进度、执行结果)等不断的返回给上层请求。
通信接口将资源调度的运行内核与外界进行隔离,隐藏其内部工作机制和实现,既保障了资源调度的有序进行,又可以让内部核心工作运行不受上层业务逻辑的干扰,保障其运行期间的稳定、健壮,它还让业务代码解耦,上层业务功能的变动不会影响运行内核的功能,而运行内核的功能扩展或者改动不会影响上层业务逻辑的功能,极大的方便了后期的功能扩展和维护。
第二步,创建一个线程数量为1的线程池,用来运行加解密任务和文件处理的IO读写以及加解密任务的运行状态的管理,如进度、结果状态、错误信息等按加解密任务的优先级进行任务加解密,对外暴露加密解密请求接口和任务处理状态的接口,供其他进程进行加解密的请求和状态访问。
同时,生命周期管理会同步工作,保证应用在后台时可以长久运行,保障加解密任务队列不会被轻易打断,同时保护加解密任务的重要信息,以便当加解密核心进程在被***或用户暴力中断的情况下,下次重新运行可以无缝复原工作状态,保证数据的安全,当应用离开用户界面后台运行时,当所有任务全部完成后,主动杀掉加解密核心进程,释放所有所占资源。
第三步,根据任务优先级进行资源分配。
抢占式动态资源分配过程如下:当收到多个加解密的请求时,将这些请求保存到优先级队列中。请求队列会根据请求的优先级进行排序,优先级高的排在前面,同等优先级的根据请求提交的时间戳进行第二轮排序。如果当前没有加解密任务正在运行,那直接从请求队列中依次取出进行加解密任务处理,如果当前有任务正在处理,则取出队列的第一个请求与当前任务的优先级对比,如果优先级高于当前任务,则保留当前任务的关键信息参数,然后丢弃掉当前任务并将其加入请求队列中后续处理,如果没有高于当前进行任务的优先级,则当前任务继续进行。
本发明的调度方法的原理是:硬件加密只有一个通信通道,如果不进行资源的统一分配和调度,在多个加解密任务的并发请求状态下,会造成长时间的通道阻塞,严重消耗手机***资源,而且大量任务请求时抢占硬件资源会造成数据丢失、或者文件加解密读写乱码等严重的问题。
本专利发明针对用户终端在多应用、多进程状态下调用硬件设备资源存在效率低下、资源抢占导致***崩溃、加解密失败以及存储数据无法进行安全隔离等情况,做出了优化,在不同情景下,根据不同的需求,合理的分配硬件设备资源,保证在文件加解密的过程中同时能进行其他的任务,提高文件加解密效率,保证***的正常运行。
对于批量处理文件加解密的任务,创建了线程池,根据任务优先级分配硬件资源,一方面减少内存消耗,另一方面便于***资源管理。
以上仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种多进程抢占硬件key加解密资源的调度方法,其特征在于,包括如下步骤:
步骤1、启动文件加解密服务,自动创建性能状态的线程池;
步骤2、硬件key等待加解密任务的提交,并定义文件加解密优先级,按优先等级进行加解密任务;
步骤3、侦测是否有业务数据,暂停加解密任务,任务可继续提交;
步骤4、释放硬件key资源,丢弃正在加解密的文件;
步骤5、等业务数据完成后,继续文件加解密任务。
2.根据权利要求1所述的调度方法,其特征在于,所述步骤2中,硬件key定义文件加解密状态的优先级,以文件的优先级来分配硬件key的资源调度,优先级相同的以提交的顺序进行加解密资源的分配。
3.根据权利要求1所述的调度方法,其特征在于,已经被文件加解密任务抢占的硬件key资源会主动释放,并丢弃正在加解密的文件,当业务数据处理完成后,文件加解密任务会立即恢复原有状态,继续进行文件加解密任务。
4.根据权利要求1所述的调度方法,其特征在于,所述硬件key会监听加解密***全局的资源调度,硬件key的资源控制中心会暂停文件加解密任务,但任务可以继续提交并在队列中等待,一直到文件线程池满载为止。
5.根据权利要求1所述的调度方法,其特征在于,所述硬件key基于线程池框架,设置一个加解密任务调度框架,用于并发数量的控制、文件加解密状态的感知、资源抢占的暂停与恢复以及文件加解密处理结果全局通知,其中:
并发数量的控制保证硬件key在同一时间进程任务数量的控制,保证***在能承受的最大阈值内平稳地运行,维持稳定的加解密***环境;
文件加解密状态的感知功能主要用于判断加解密***是否在执行、暂停以及恢复加解密任务,对于文件加解密任务的执行感知主要为了创建文件加解密任务的线程池,从而方便管理线程,减少对硬件资源的消耗;
文件加解密任务的暂停与恢复的感知主要用于判断在执行通话和信息等过程中或者结束后,保证文件加解密任务的暂停和恢复;
文件加解密处理结果全局通知功能用于对加解密***各种应用***执行前的判断。
6.根据权利要求1所述的调度方法,其特征在于,所述硬件key对多任务进程处理的方法,包括如下步骤:
当多个任务同时要进行加解密时,发送请求到通信接口;
创建一个线程数量为1的线程池,用来运行加解密任务和文件处理的IO读写以及加解密任务的运行状态的管理,按加解密任务的优先级进行任务加解密,对外暴露加密解密请求接口,和任务处理状态的接口,供其他进程进行加解密的请求和状态访问;
根据任务优先级进行资源分配,当收到多个加解密的请求时,将这些请求保存到优先级队列中。
7.根据权利要求6所述的调度方法,其特征在于,所述通信接口的应用方法,包括如下步骤:
当上层业务需要请求加解密时,首先将请求信息打包封装成消息对象,发送到通信接口;
通信接口对请求信息进行解析、判断是否是有效请求,如果是有效请求,则保存关键信息参数,然后传递给内部请求队列,如果是无效请求,则直接丢弃并接返回;
提交成功的请求,通信接口还会携带当前任务的执行状态不断的返回给上层请求。
8.根据权利要求6所述的调度方法,其特征在于,所述线程池的生命周期管理模块会同步工作,用于保障加解密任务队列不会被轻易打断,同时保护加解密任务的重要信息;
当加解密核心进程在中断的情况下,重新运行无缝复原工作状态,
当所有任务全部完成后,生命周期管理模块主动杀掉加解密核心进程,释放所有所占资源。
9.根据权利要求1所述的调度方法,其特征在于,在加解密***内设置了各个与加解密相关的业务,当这些业务串行时,会涉及应用与硬件key的基本通信和密钥交换,通过硬件key设置调度中心,所述调度中心,配置一个业务调度池,所述业务调度池通过硬件key返回状态进行判断然后调度,当目前硬件key状态为空闲态时,从业务优先队列中获取到最高业务进程并执行;当目前硬件key状态为占用态时,根据硬件返回特殊码,执行对应进程。
10.根据权利要求9所述的调度方法,其特征在于,当硬件key状态为占用态时,硬件返回多种特殊码,根据所述特殊码的不同,硬件key设置安全域环境并设定了一个业务的指令集执行顺序,具体是:
第一特殊码是执行耗时较久的指令,根据第一特殊码,调度中心让多线程执行一些耗时的任务、IO(Input/Output)收发、资源释放、性能调整;
第二特殊码是安全域环境初始化,调度中心执行同进程的安全域环境下的剩余指令,其余进程和同进程其他指令都不进行调度处理;
第三特殊码是组合指令结束,但安全域环境未结束,调度中心把同进程的指令优先级调高;
第四特殊码是安全域环境结束,代表该线程的任务马上结束,调度中心停止优先队列的调整工作,获取优先级最高的任务指令,并从数据集合中把对应的源数据调出来,准备新业务开始。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210453521.7A CN114840318A (zh) | 2022-04-27 | 2022-04-27 | 一种多进程抢占硬件key加解密资源的调度方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210453521.7A CN114840318A (zh) | 2022-04-27 | 2022-04-27 | 一种多进程抢占硬件key加解密资源的调度方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114840318A true CN114840318A (zh) | 2022-08-02 |
Family
ID=82567179
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210453521.7A Pending CN114840318A (zh) | 2022-04-27 | 2022-04-27 | 一种多进程抢占硬件key加解密资源的调度方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114840318A (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115221543A (zh) * | 2022-08-30 | 2022-10-21 | 成都瑞安信信息安全技术有限公司 | 一种基于档案业务多文件并发加解密方法及*** |
CN115495223A (zh) * | 2022-11-18 | 2022-12-20 | 安徽华云安科技有限公司 | 任务安全调度方法、装置、设备以及存储介质 |
CN116339956A (zh) * | 2023-05-29 | 2023-06-27 | 天翼云科技有限公司 | 一种配置任务的分发方法、装置、电子设备及存储介质 |
-
2022
- 2022-04-27 CN CN202210453521.7A patent/CN114840318A/zh active Pending
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115221543A (zh) * | 2022-08-30 | 2022-10-21 | 成都瑞安信信息安全技术有限公司 | 一种基于档案业务多文件并发加解密方法及*** |
CN115221543B (zh) * | 2022-08-30 | 2022-11-29 | 成都瑞安信信息安全技术有限公司 | 一种基于档案业务多文件并发加解密方法及*** |
CN115495223A (zh) * | 2022-11-18 | 2022-12-20 | 安徽华云安科技有限公司 | 任务安全调度方法、装置、设备以及存储介质 |
CN116339956A (zh) * | 2023-05-29 | 2023-06-27 | 天翼云科技有限公司 | 一种配置任务的分发方法、装置、电子设备及存储介质 |
CN116339956B (zh) * | 2023-05-29 | 2023-10-10 | 天翼云科技有限公司 | 一种配置任务的分发方法、装置、电子设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7197612B2 (ja) | オンデマンドネットワークコード実行システム上での補助機能の実行 | |
CN114840318A (zh) | 一种多进程抢占硬件key加解密资源的调度方法 | |
CN108139940B (zh) | 对于计算能力的周期性请求的管理 | |
CN107291547B (zh) | 一种任务调度处理方法、装置及*** | |
US8424007B1 (en) | Prioritizing tasks from virtual machines | |
US9218203B2 (en) | Packet scheduling in a multiprocessor system using inter-core switchover policy | |
US8756613B2 (en) | Scalable, parallel processing of messages while enforcing custom sequencing criteria | |
EP3306866B1 (en) | Message processing method, device and system | |
CN106411558B (zh) | 一种数据流量限制的方法及*** | |
CN112181621A (zh) | 一种任务调度***、方法、设备及存储介质 | |
CN106034120B (zh) | 一种多进程访问可信应用的方法和*** | |
CN104102548A (zh) | 任务资源调度处理方法和*** | |
CN115167996A (zh) | 调度方法及装置、芯片、电子设备及存储介质 | |
CN115237556A (zh) | 调度方法及装置、芯片、电子设备及存储介质 | |
CN111586140A (zh) | 一种数据交互的方法及服务器 | |
WO2016033755A1 (zh) | 任务处理装置、电子设备及方法 | |
US9507637B1 (en) | Computer platform where tasks can optionally share per task resources | |
CN111651279A (zh) | 一种处理业务流程的方法及其处理*** | |
CN112799851B (zh) | 多方安全计算中的数据处理方法和相关装置 | |
CN111767125B (zh) | 任务执行方法、装置、电子设备、存储介质 | |
CN116700901A (zh) | 基于微内核的容器构建与运行***及方法 | |
US8869171B2 (en) | Low-latency communications | |
US12019909B2 (en) | IO request pipeline processing device, method and system, and storage medium | |
Vanga et al. | Supporting low-latency, low-criticality tasks in a certified mixed-criticality OS | |
JP2009541852A (ja) | コンピュータマイクロジョブ |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |