CN117453413A - 资源申请方法、装置、电子设备以及存储介质 - Google Patents

资源申请方法、装置、电子设备以及存储介质 Download PDF

Info

Publication number
CN117453413A
CN117453413A CN202311500125.6A CN202311500125A CN117453413A CN 117453413 A CN117453413 A CN 117453413A CN 202311500125 A CN202311500125 A CN 202311500125A CN 117453413 A CN117453413 A CN 117453413A
Authority
CN
China
Prior art keywords
target
lock
state
resource
target process
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
Application number
CN202311500125.6A
Other languages
English (en)
Inventor
刘源
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangdong Oppo Mobile Telecommunications Corp Ltd
Original Assignee
Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Guangdong Oppo Mobile Telecommunications Corp Ltd filed Critical Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority to CN202311500125.6A priority Critical patent/CN117453413A/zh
Publication of CN117453413A publication Critical patent/CN117453413A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/45Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
    • G06F8/458Synchronisation, e.g. post-wait, barriers, locks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • G06F9/4418Suspend and resume; Hibernate and awake
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526Mutual exclusion algorithms

Abstract

本申请公开了一种资源申请方法、装置、电子设备以及存储介质,涉及电子设备技术领域。接收目标进程对目标资源的申请,在等待分配目标资源给目标进程的情况下,确定目标进程在申请目标资源时针对中央处理器的占有状态,其中,该占有状态包括独占状态或者非独占状态,目标进程在等待分配目标资源的过程中处于休眠状态,目标进程在休眠状态下让出中央处理器的调度,若确定占有状态为独占状态,则保持占有状态为独占状态直到将目标资源分配至目标进程。本申请通过针对带有休眠行为和让出中央处理器的调度的资源申请场景,在识别到进程是独占中央处理器的状态时,继续保持独占中央处理器的状态,可以避免系统崩溃或死机的问题。

Description

资源申请方法、装置、电子设备以及存储介质
技术领域
本申请涉及电子设备技术领域,更具体地,涉及一种资源申请方法、装置、电子设备以及存储介质。
背景技术
随着科学技术的发展,电子设备的使用越来越广泛,功能越来越多,已经成为人们日常生活中的必备之一。其中,电子设备可以运行有进程,且进程可以进行资源申请,但是由于电子设备的资源有限,进程往往需要等待电子设备进行资源分配,然而在等待过程中容易出现系统崩溃或死机的问题。
发明内容
鉴于上述问题,本申请提出了一种资源申请方法、装置、电子设备以及存储介质,以解决上述问题。
第一方面,本申请实施例提供了一种资源申请方法,所述方法包括:接收目标进程对目标资源的申请;在等待分配所述目标资源给所述目标进程的情况下,确定所述目标进程在申请所述目标资源时针对中央处理器的占有状态,其中,所述占有状态包括独占状态或者非独占状态,所述目标进程在等待分配所述目标资源的过程中处于休眠状态,所述目标进程在休眠状态下让出中央处理器的调度;若确定所述占有状态为独占状态,则保持所述占有状态为独占状态直到将所述目标资源分配至所述目标进程。
第二方面,本申请实施例提供了一种资源申请装置,所述装置包括:申请接收模块,用于接收目标进程对目标资源的申请;占有状态确定模块,用于在等待分配所述目标资源给所述目标进程的情况下,确定所述目标进程在申请所述目标资源时针对中央处理器的占有状态,其中,所述占有状态包括独占状态或者非独占状态,所述目标进程在等待分配所述目标资源的过程中处于休眠状态,所述目标进程在休眠状态下让出中央处理器的调度;状态控制模块,用于若确定所述占有状态为独占状态,则保持所述占有状态为独占状态直到将所述目标资源分配至所述目标进程。
第三方面,本申请实施例提供了一种电子设备,包括存储器和处理器,所述存储器耦接到所述处理器,所述存储器存储指令,当所述指令由所述处理器执行时所述处理器执行上述方法。
第四方面,本申请实施例提供了一种计算机可读取存储介质,所述计算机可读取存储介质中存储有程序代码,所述程序代码可被处理器调用执行上述方法。
本申请实施例提供的资源申请方法、装置、电子设备以及存储介质,接收目标进程对目标资源的申请,在等待分配目标资源给目标进程的情况下,确定目标进程在申请目标资源时针对中央处理器的占有状态,其中,该占有状态包括独占状态或者非独占状态,目标进程在等待分配目标资源的过程中处于休眠状态,目标进程在休眠状态下让出中央处理器的调度,若确定占有状态为独占状态,则保持占有状态为独占状态直到将目标资源分配至目标进程,从而通过针对带有休眠行为和让出中央处理器的调度的资源申请场景,在识别到进程是独占中央处理器的状态时,继续保持独占中央处理器的状态,可以避免系统崩溃或死机的问题。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下方将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下方描述中的附图仅仅是本申请的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1示出了进程正常、独占CPU、以及休眠时的时间片分布的对比示意图;
图2示出了申请锁和释放锁的流程示意图;
图3示出了目前针对多次申请同一个锁的流程示意图;
图4示出了目前针对多次申请同一个锁造成的死锁示意图;
图5示出了目前针对持有自旋锁后申请互斥锁的流程示意图;
图6示出了目前针对持有自旋锁后申请互斥锁造成的死锁示意图;
图7示出了目前针对中断处理后申请互斥锁的流程示意图;
图8示出了本申请一实施例提供的资源申请方法的流程示意图;
图9示出了本申请一实施例提供的资源申请方法的流程示意图;
图10示出了本申请的图9所示的资源申请方法的步骤S230的流程示意图;
图11示出了本申请一实施例提供的资源申请方法的流程示意图;
图12示出了本申请一实施例提供的资源申请方法的流程示意图;
图13示出了本申请实施例中目标资源为目标锁时的资源申请的流程示意图;
图14示出了在将本申请实施例所提供的方案应用于多次申请同一个锁的场景时的流程示意图;
图15示出了在将本申请实施例所提供的方案应用于多次释放同一个锁的场景时的流程示意图;
图16示出了在将本申请实施例所提供的方案应用于持有自旋锁后申请互斥锁的场景时的流程示意图;
图17示出了在将本申请实施例所提供的方案应用于中断处理后申请互斥锁的场景时的流程示意图;
图18示出了本申请一实施例提供的资源申请装置的模块框图;
图19示出了本申请实施例用于执行根据本申请实施例的资源申请方法的电子设备的框图;
图20示出了本申请实施例的用于保存或者携带实现根据本申请实施例的资源申请方法的程序代码的存储单元。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案,下方将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述。
下面将针对本申请实施例所可能涉及的名词进行说明。
进程调度、CPU调度:无论是在批处理系统还是分时系统中,用户进程数一般都多于处理机数,这将导致它们互相争夺处理机。另外,系统进程也同样需要使用处理机,这就要求进程调度程序按一定的策略,动态地把处理机分配给处于就绪队列中的某一个进程,以使之执行。
如图1所示,一个CPU上会跑多个进程,表面上看多个进程是同时在运行。其实进程调度模块会把时间分片,给每个进程分配一个时间段,使每个进程轮流执行。如果某个进程调用了“关闭抢占”的系统接口(示例:Linux系统中的preempt_disable()),进程调度模块就允许该进程“独占CPU”。直到该进程调用“恢复抢占”的系统接口(Linux系统中的preempt_enable()),进程调度模块继续按时间片机制轮流执行每个进程。如果某个进程调用了“休眠”的系统接口(示例:Linux系统中的ssleep()),进程调度模块可以把原本分配给该进程的时间片挪给其它进程使用,实现整体最大效率的资源利用。
时间片:时间片(timeslice)又称为“量子(quantum)”或“处理器片(processorslice)”是分时操作系统分配给每个正在运行的进程微观上的一段CPU时间(在抢占内核中是:从进程开始运行直到被抢占的时间)。现代操作系统(如:Windows、Linux、Mac OS X等)允许同时运行多个进程——例如,可以在打开音乐播放器听音乐的同时用浏览器浏览网页并下载文件。事实上,虽然一台计算机通常可能有多个CPU,但是同一个CPU永远不可能真正地同时运行多个任务。在只考虑一个CPU的情况下,这些进程“看起来像”同时运行的,实则是轮番穿插地运行,由于时间片通常很短(在Linux上为5ms-800ms),用户不会感觉到。
抢占:系统把处理机分配给优先权最高的进程,使之执行。但在其执行期间,只要又出现了另一个其优先权更高的进程,进程调度程序就立即停止当前进程(原优先权最高的进程)的执行,重新将处理机分配给新到的优先权最高的进程。
锁:在编程中,引入了对象互斥锁的概念,来保证共享数据操作的完整性。每个对象都对应于一个可称为互斥锁的标记,这个标记用来保证在任一时刻,只能有一个线程访问该对象。操作系统通过锁机制,保证在多核多线程环境中的某一个时间点上,只有一个线程(注:在Linux内核中也可以称为进程)访问某种共享资源,从而保证数据一致性。关于锁的使用,最重要的两个操作就是申请锁(获得锁的占有权的过程(包括等锁释放))和释放锁(让出锁的占有权的过程),下面通过如图2所示的流程图展开描述。
1)目标进程开始运行。
2)目标进程需要访问受目标锁保护的一个共享资源。
3)目标进程调用系统接口[申请锁](示例:Linux系统中的spin_lock()、mutex_lock())。
4)判断目标锁有没有持锁者。
5)如果目标锁没有持锁者,反馈给目标进程“申请锁成功”的信息。
6)目标进程正常访问共享资源。
7)访问完成之后,目标进程调用系统接口[释放锁](示例:Linux系统中的spin_unlock()、mutex_unlock())。
8)在步骤4中(判断目标锁有没有持锁者),如果目标锁有持锁者,反馈给目标进程“要等锁释放”的信息。
9)目标进程等待锁释放。
10)若干时间之后,当目标锁被持锁者释放,跳转到步骤5(反馈给目标进程“申请锁成功”的信息)。
其中,锁的类型可以包括自旋锁和互斥锁。自旋锁(示例:Linux系统中的spin_lock())的特性在于,进程在持锁和等锁期间,都处于“独占CPU”的状态(示例:Linux系统中的preempt_disable())。互斥锁(示例:Linux系统中的mutex_lock())的特性在于,进程在等锁期间,会进入休眠状态,允许CPU调度切到其它进程,等到申请锁成功后再切回来,恢复正常的CPU调度状态。
中断:指处理机处理程序运行中出现的紧急事件的整个过程。程序运行过程中,系统外部、系统内部或者现行程序本身若出现紧急事件,处理机立即中止现行程序的运行,自动转入相应的处理程序(中断服务程序),待处理完后,再返回原来的程序运行,这整个过程称为程序中断。一般说中断,主要是指处理器在接收到来自外围硬件(相对于中央处理器和内存)的异步信号,操作系统都有对应的中断处理程序来及时响应各种中断信号。中断处理程序相对于常规进程的一个重要差异在于,会调用“关闭中断”(示例:Linux系统中的local_irq_disable())、“关闭抢占”(示例:Linux系统中的preempt_disable())的系统接口。所以中断处理程序的调用优先级非常高。
死锁:死锁是指两个或两个以上的进程在执行过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程。
Panic:内核错误(Kernel panic)是指操作系统在监测到内部的致命错误,并无法安全处理此错误时采取的动作。这个概念主要被限定在Unix以及类Unix系统中;对于MicrosoftWindows系统,等同的概念通常被称为蓝屏死机。
Watchdog:看门狗,又叫watchdog timer,是一个定时器电路,一般有一个输入,叫喂狗(kicking the dog/service the dog),一个输出到MCU的RST端,MCU正常工作的时候,每隔一段时间输出一个信号到喂狗端,给WDT清零,如果超过规定的时间不喂狗(一般在程序跑飞时),WDT定时超过,就会给出一个复位信号到MCU,使MCU复位。防止MCU死机.看门狗的作用就是防止程序发生死循环,或者说程序跑飞。
如图3所示,目前针对多次申请同一个锁的场景可以由以下流程实现:
1、目标进程开始运行。
2、目标进程需要访问受目标锁保护的一个共享资源。
3、目标进程调用系统接口[申请锁]。
4、判断目标锁有没有持锁者。
5、如果目标锁没有持锁者,设置持锁者为目标进程。
6、反馈给目标进程“申请锁成功”的信息。
7、目标进程正常访问共享资源。
8、目标进程继续正常运行。
9、目标进程需要访问受目标锁保护的另一个共享资源。
10、目标进程调用系统接口[申请锁]。
11、判断目标锁有没有持锁者。
12如果目标锁有持锁者,反馈给目标进程“要等锁释放”的信息。
13、目标进程等待锁释放。
14、这里出现了死循环,也就是所说的“死锁”。目标进程在已经持有目标锁的状态下,又在尝试申请该锁、等待持锁者(即自己)释放锁。所以目标进程无法继续正常运行,如图4所示。
如图5所示,目前针对持有自旋锁后申请互斥锁的场景可以由以下流程实现:
1、目标进程开始运行。
2、目标进程需要访问受自旋锁保护的一个共享资源。
3、目标进程调用系统接口[申请锁]。
4、判断自旋锁有没有持锁者。
5、如果自旋锁没有持锁者,设置持锁者为目标进程。
6、反馈给目标进程“申请锁成功”的信息。
7、由于自旋锁的特性,目标进程会独占CPU,即,所在CPU只服务于该进程,分配到该CPU上的其它进程都无法运行。
8、目标进程正常访问共享资源。
9、目标进程继续正常运行。
10、目标进程需要访问受互斥锁保护的一个共享资源。
11、目标进程调用系统接口[申请锁]。
12、判断互斥锁有没有持锁者。
13、如果互斥锁有持锁者,反馈给目标进程“要等锁释放”的信息。
14、由于互斥锁的特性,目标进程不再独占CPU,以休眠方式等待锁释放。
15、另一个进程得到了调度,开始运行。
16、另一个进程需要访问受自旋锁保护的一个共享资源。
17、另一个进程调用系统接口[申请锁]。
18、判断自旋锁有没有持锁者
19、如果自旋锁有持锁者,反馈给另一个进程“要等锁释放”的信息。
20、由于自旋锁的特性,另一个进程会独占CPU。
21、这里出现了死循环,也就是所说的“死锁”。目标进程持有自旋锁、但是得不到CPU调度(没有机会释放自旋锁),而另一个进程独占CPU、却在等自旋锁释放,如图6所示。
如图7所示,目前针对中断处理后申请互斥锁的场景可以由以下流程实现:
1、中断处理开始运行。
2、中断处理独占CPU。
3、中断处理需要访问受互斥锁保护的一个共享资源。
4、中断处理调用系统接口[申请锁]。
5、判断互斥锁有没有持锁者。
6、如果互斥锁有持锁者,反馈给中断处理“要等锁释放”的信息。
7、由于互斥锁的特性——等待期间允许抢占,中断处理不再独占CPU,以休眠方式等待锁释放。
8、由于CPU调度主要是针对常规进程的管控,调度到若干常规进程运行后、再也无法调度回到这个中断处理,于是这个中断处理占有的资源就再也无法释放、也就是所说的“资源泄漏”。
针对上述问题,发明人经过长期的研究发现,并提出了本申请实施例提供的资源申请方法、装置、电子设备以及存储介质,通过针对带有休眠行为和让出中央处理器的调度的资源申请场景,在识别到进程是独占中央处理器的状态时,继续保持独占中央处理器的状态,可以避免系统崩溃或死机的问题。其中,具体的资源申请方法在后续的实施例中进行详细的说明。
请参阅图8,图8示出了本申请一实施例提供的资源申请方法的流程示意图。该方法用于通过针对带有休眠行为和让出中央处理器的调度的资源申请场景,在识别到进程是独占中央处理器的状态时,继续保持独占中央处理器的状态,可以避免系统崩溃或死机的问题。在具体的实施例中,该资源申请方法应用于如图18所示的资源申请装置200以及配置有资源申请装置200的电子设备100(图19)。下面将以电子设备为例,说明本实施例的具体流程,当然,可以理解的,本实施例所应用的电子设备可以包括智能手机、平板电脑、穿戴式电子设备等,在此不做限定。下面将针对图1所示的流程进行详细的阐述,所述资源申请方法具体可以包括以下步骤:
步骤S110:接收目标进程对目标资源的申请。
可选地,对目标资源的申请可以包括:对信号量的申请(示例:Linux系统中的down())、对内存的申请(示例:Linux系统中的kmalloc())、对内核空间和用户空间数据的拷贝申请(示例:Linux系统中的copy_to_user()、copy_from_user())、对延时的申请(示例:Linux系统中的ssleep())、对目标锁的申请(示例:互斥锁、自旋锁)等,在此不做限定。
在本实施例中,可以接收目标进程对目标资源的申请。
在一些实施方式中,电子设备可以运行目标进程,当目标进程需要访问目标资源时,可以发起对目标资源的申请,相应地,可以接收目标进程对目标资源的申请。作为一种方式,该目标进程可以在电子设备的前台运行,可以在电子设备的后台运行,也可以在电子设备的前台和后台切换运行等,在此不做限定。
在一些实施方式中,目标进程可以通过调用第一目标系统接口的方式,发起对目标资源的申请。基于此,电子设备在运行目标进程的过程中,可以检测目标进程是否调用第一目标系统接口,若检测到目标进程调用第一目标系统接口,则可以确定目标进程发起对目标资源的申请,可以接收目标进程对目标资源的申请。
步骤S120:在等待分配所述目标资源给所述目标进程的情况下,确定所述目标进程在申请所述目标资源时针对中央处理器的占有状态,其中,所述占有状态包括独占状态或者非独占状态,所述目标进程在等待分配所述目标资源的过程中处于休眠状态,所述目标进程在休眠状态下让出中央处理器的调度。
在一些实施方式中,电子设备在接收到目标进程对目标资源的申请的情况下,可以判断目标进程是否需要等待目标资源的分配。其中,若判断结果表征目标进程需要等待目标资源的分配,则可以发送等待指示至目标进程,相应地,目标进程等待分配目标资源;若判断结果表征目标进程不需要等待目标资源的分配,则可以直接将目标资源分配给目标进程,相应地,目标进程可以占有该目标资源。
作为一种可实施的方式,电子设备在接收到目标进程对目标资源的申请的情况下,可以判断目标资源是否处于紧张状态。其中,若确定目标资源处于紧张状态,则可以确定目标进程需要等待目标资源的分配;若确定目标资源处于不紧张状态,则可以确定目标进程不需要等待目标资源的分配。
作为又一种可实施的方式,电子设备在接收到目标进程对目标资源的申请的情况下,可以获取目标进程对目标资源的申请量,并获取目标资源的空闲量,确定申请量和空闲量之间的大小关系。其中,若大小关系表征申请量小于或等于空闲量,则可以确定目标进程不需要等待目标资源的分配;若大小关系表征申请量大于空闲量,则可以确定目标进程需要等待目标资源的分配。
作为再一种可实施的方式,电子设备在接收到目标进程对目标资源的申请的情况下,可以判断目标资源是否处于被占用的状态。其中,若确定目标资源处于被占用的状态,则可以确定目标进程需要等待目标资源的分配;若确定目标资源处于未被占用的状态,则可以确定目标进程不需要等待目标资源的分配。
其中,在确定目标进程需要等待目标资源的分配的情况下,目标进程可以进入等待模式以等待分配目标资源,可选地,目标进程在等待分配目标资源的过程中处于休眠状态,且目标进程在休眠状态下让出中央处理器的调度。可以理解的是,目标进程处于休眠状态时,进程调度模块可以把原本分配给目标进程的时间片挪给其它进程使用,以实现整体最大效率的资源利用,即目标进程会让出中央处理器的调度。
在本实施例中,在等待分配目标资源给目标进程的情况下,可以确定目标进程在申请该目标资源时针对中央处理器的占有状态。可选地,该占有状态可以包括独占状态或者非独占状态。其中,独占状态是指如果一个进程或线程独占了某个或某些CPU,那么,其它进程或线程就不能在该CPU上运行,独占CPU通常是为了保证某个进程或线程的性能和稳定性。非独占状态是指多个进程或线程可以共享同一个CPU资源,并根据各自的优先级和调度策略来分配CPU时间片,非独占CPU可以提高系统的并发性和响应速度。
作为一种可实施的方式,可以通过查看目标进程在申请该目标资源时的CPU使用率的方式,确定目标进程在申请该目标资源时针对中央处理器的占有状态。例如,可以使用系统自带的命令行工具(如top、htop等)来查看目标进程在申请该目标资源时的CPU使用率,如果该目标进程在申请该目标资源时的CPU使用率接近100%,则可以确定目标进程在申请该目标资源时针对中央处理器的占有状态为独占状态,否则,可以确定目标进程在申请该目标资源时针对中央处理器的占有状态为非独占状态。
作为又一种可实施的方式,可以通过查看目标进程在申请该目标资源时的优先级的方式,确定目标进程在申请该目标资源时针对中央处理器的占有状态。例如,可以使用命令行工具(如ps、top等)来查看目标进程在申请该目标资源时的优先级,可以理解的是,进程的优先级越高,其获得CPU资源的机会就越大,因此,如果目标进程的优先级比其他进程高很多,那么,可以确定该目标进程在申请该目标资源时针对中央处理器的占有状态为独占状态,否则,可以确定目标进程在申请该目标资源时针对中央处理器的占有状态为非独占状态。
作为再一种可实施的方式,可以通过查看目标进程在申请该目标资源时的程序代码的方式,确定目标进程在申请该目标资源时针对中央处理器的占有状态。例如,可以通过查看目标进程在申请该目标资源时程序代码,确定是否存在对CPU资源的独占性操作,例如是否存在使用锁、条件变量等,如果存在对CPU的资源的独占性操作,则可以确定目标进程在申请该目标资源时针对中央处理器的占有状态的独占状态,否则,可以确定目标进程在申请该目标资源时针对中央处理器的占有状态为非独占状态。
在一些实施方式中,若目标进程在申请目标资源时持有自旋锁,则可以确定目标进程在申请目标资源时针对中央处理器的占有状态为独占状态。其中,可以理解的是,由于自旋锁的特性,目标进程所在CPU只服务于该目标进程,分配到该CPU上的其它进程都无法运行,因此,如果确定目标进程在申请目标资源时持有自旋锁,则可以确定目标进程在申请目标资源时针对中央处理器的占有状态为独占状态。
在一些实施方式中,若目标进程为中断服务程序,则可以确定目标进程在申请目标资源时针对中央处理器的占有状态为独占状态。其中,可以理解的是,中断服务程序的调用优先级非常高,在调用期间会调用“关闭抢占”的系统接口,其它进程则无法在该CPU上运行,因此,如果确定目标进程为中断服务程序,则可以确定目标进程在申请目标资源时针对中央处理器的占有状态为独占状态。
在一些实施方式中,在确定目标进程应用在Android系统中的DECLARE_HOOK()或DECLARE_RESTRICTED_HOOK()等场景时,可以确定目标在申请目标资源时针对中央处理器的占有状态为独占状态。
步骤S130:若确定所述占有状态为独占状态,则保持所述占有状态为独占状态直到将所述目标资源分配至所述目标进程。
在本实施例中,若确定目标进程在申请目标资源时针对中央处理器的占有状态为独占状态,则可以保持占有状态为独占状态,直到将目标资源分配至目标进程。可以理解的是,通过保持占有状态为独占状态直到将目标资源分配至目标进程的方式,实现保持对中央处理器的调度,可以避免目标进程在等待分配目标资源给目标进程的过程中让出中央处理器的调度,从而造成系统崩溃或死机的问题。
在一些实施方式中,若目标资源为信号量,则可以保持占有状态为独占状态,直到将信号量分配至目标进程;若目标资源为内存,则可以保持占有状态为独占状态,直到将内存分配至目标进程;若目标资源为目标锁,则可以保持占有状态为独占状态,直到将目标锁分配至目标进程等,在此不做限定。
本申请一实施例提供的资源申请方法,接收目标进程对目标资源的申请,在等待分配目标资源给目标进程的情况下,确定目标进程在申请目标资源时针对中央处理器的占有状态,其中,该占有状态包括独占状态或者非独占状态,目标进程在等待分配目标资源的过程中处于休眠状态,目标进程在休眠状态下让出中央处理器的调度,若确定占有状态为独占状态,则保持占有状态为独占状态直到将目标资源分配至目标进程,从而通过针对带有休眠行为和让出中央处理器的调度的资源申请场景,在识别到进程是独占中央处理器的状态时,继续保持独占中央处理器的状态,可以避免系统崩溃或死机的问题。
请参阅图9,图9示出了本申请一实施例提供的资源申请方法的流程示意图。在本实施例中,目标资源为目标锁,下面将针对图9所示的流程进行详细的阐述,所述资源申请方法具体可以包括以下步骤:
步骤S210:接收目标进程对目标锁的申请。
可选地,目标资源可以包括目标锁。其中,该目标锁可以包括互斥锁、自旋锁等,在此不做限定。
在本实施例中,可以接收目标进程对目标锁的申请。在一些实施方式中,电子设备可以开始运行目标进程,若目标进程需要访问受目标锁保护的一个共享资源,则目标进程可以调用系统接口申请目标锁,相应地,电子设备可以接收目标进程对目标锁的申请。
步骤S220:确定所述目标锁对应的第一持有状态,其中,所述第一持有状态包括有持锁者或者无持锁者。
在本实施例中,在接收到目标进程针对目标锁的申请的情况下,可以确定目标锁对应的第一持有状态,其中,该第一持有状态可以包括有持锁者或者无持锁者。在一些实施方式中,在接收到目标进程对目标锁的申请的情况下,可以判断目标锁是否有持锁者,如果判断到目标锁有持锁者,则可以确定目标锁对应的第一持有状态为有持锁者;如果判断到目标锁没有持锁者,则可以确定目标锁对应的第一持有状态为无持锁者。
作为一种可实施的方式,可以通过调试工具判断目标锁是否有持锁者。例如,可以使用调试工具检测程序的状态,包括锁的持有情况,在调试工具中,可以查看线程的状态和锁的持有情况,从而可以确定目标锁是否有持锁者。
作为又一种可实施的方式,可以通过编写代码判断目标锁是否有持锁者。例如,可以在程序中编写代码来判断是否有线程持有目标锁,如可以编写一个函数来尝试获得目标锁,并在函数中添加判断逻辑,以确定目标锁是否有持锁者。
作为再一种可实施的方式,可以通过系统监控工具判断目标锁是否有持锁者,例如,可以使用系统监控工具来查看程序的状态,包括锁的持有情况,如在Linux系统中,可以使用top命令或htop命令来查看进程的状态和资源使用情况,包括目标锁的持有情况,以确定目标锁是否有持锁者。
步骤S230:若确定所述第一持有状态为有持锁者,则确定需要等待所述目标锁被释放。
在一些实施方式中,若确定第一持有状态为有持锁者,则可以确定需要等待目标锁被释放。其中,若确定第一持有状态为有持锁者,可以反馈给目标进程“要等锁释放”的信息,相应地,目标进程等待目标锁被释放。
在一些实施方式中,若确定第一持有状态为无持锁者,则可以确定不需要等待目标锁被释放,其中,若确定第一持有状态为无持锁者,可以将目标锁的持锁者设置为目标进程,反馈给目标进程“申请锁成功”的信息,相应地,目标进程可以持有该目标锁。
请参阅图10,图10示出了本申请的图9所示的资源申请方法的步骤S230的流程示意图。下面将针对图10所示的流程进行详细的阐述,所述方法具体可以包括以下步骤:
步骤S231:若确定所述第一持有状态为有持锁者,则确定所述目标锁对应的目标持锁者。
在本实施例中,若确定第一持有状态为有持锁者,则可以确定目标锁对应的目标持锁者。可选地,目标锁对应的目标持锁者可以为目标进程,或者,可以为不同于目标进程的其它进程。
作为一种可实施的方式,若确定第一持有状态为有持锁者,则可以使用调试工具确定目标锁对应的目标持锁者。其中,调试工具可以用来检查程序在运行时的状态,包括锁的持有情况,一些调试工具提供了线程和锁的检查功能,可以清楚地查看哪些线程正在持有哪些锁,从而可以确定目标锁对应的目标持锁者。
作为又一种可实施的方式,若确定第一持有状态为有持锁者,则可以通过在程序中添加日志的方式确定目标锁对应的目标持锁者。其中,在程序中适当的位置添加日志,可以帮助跟踪程序的运行情况,包括锁的持有情况,例如,在获取目标锁的代码前后添加日志,可以记录哪些进程在何时获取或释放了目标锁,从而可以确定目标锁对应的目标持锁者。
作为再一种可实施的方式,若确定第一持有状态为有持锁者,则可以通过系统监控工具的方式确定目标锁对应的目标持锁者。其中,可以通过top、htop等工具查看系统中的进程状态,包括哪些进程正在持有锁,从而可以确定目标锁对应的目标持锁者。
步骤S232:若确定所述目标持锁者不是所述目标进程,则确定需要等待所述目标锁被释放。
在一些实施方式中,若确定目标持锁者不是目标进程,则可以确定需要等待目标锁被释放。其中,若确定目标持锁者为不同于目标进程的另一进程,则可以认为目标锁正在被另一进程持有,则可以确定需要等待另一进程释放目标锁,即需要等待目标锁被释放。
在一些实施方式中,若确定目标持锁者是目标进程,则可以生成第一告警信息,其中,该第一告警信息用于指示申请已持有的锁。可以理解的是,若确定目标持锁者是目标进程,则可以确定目标进程在已经持有目标锁的情况下又再次申请目标锁,即可以确定目标进程存在重复申请锁的情况,因此,可以通过生成第一告警信息的方式指示目标进程申请已持有的锁,从而实现对目标进程针对相同锁的重复申请的错误进行记录,以便于后续对该错误进行修复。可选地,第一告警信息可以包括记录日志、屏幕提示等,在此不做限定。
在一些实施方式中,若确定目标持锁者是目标进程,则可以向目标进程反馈第一信息,其中,该第一信息用于指示针对目标锁申请成功。可以理解的是,若确定目标持锁者是目标进程,则可以确定目标进程在已经持有目标锁的情况下又再次申请目标锁,既然目标进程已经持有目标锁,则可以通过向目标进程反馈用于指示针对目标锁申请锁成功的第一信息的方式,使得目标进程可以正常访问受目标锁保护的共享资源,以避免目标进程在持有目标锁的情况下等待目标锁的释放而造成的死锁问题。
在一些实施方式中,在向目标进程反馈第一信息之后,目标进程可以正常访问受目标锁保护的共享资源,在目标进程访问完共享资源之后,可以释放目标锁。因此,可以接收目标进程针对目标锁的释放请求,确定目标锁对应的第二持有状态,其中,第二持有状态包括有持锁者或者无持锁者,若确定第二持有状态为有持锁者,则将目标锁对应的第二持有状态更新为无持锁者,并向目标进程反馈第二信息,其中,该第二信息用于指示目标锁释放锁成功;若确定第二持有状态为无持锁者,则向第二目标进程反馈第二信息,并生成第二告警信息,其中,第二告警信息用于指示释放未持有的锁。
作为一种可实施的方式,电子设备可以运行目标进程,且目标进程在持有目标锁后可以正常访问受目标锁保护的共享资源,当目标进程完成对共享资源的访问时,可以发起对目标锁的释放请求,相应地,可以接收目标进程对目标锁的释放请求。可选地,目标进程可以通过调用第二目标系统接口的方式,发起对目标锁的释放请求,基于此,电子设备在运行目标进程的过程中,可以检测目标进程是否调用第二目标系统接口,若检测到目标进程调用第二目标系统接口,则可以确定目标进程发起对目标锁的释放请求,可以接收目标进程对目标锁的释放请求。
作为一种可实施的方式,在接收到目标进程针对目标锁的释放请求的情况下,可以确定目标锁对应的第二持有状态,其中,该第二持有状态可以包括有持锁者或者无持锁者。在一些实施方式中,在接收到目标进程对目标锁的释放请求的情况下,可以判断目标锁是否有持锁者,如果判断到目标锁有持锁者,则可以确定目标锁对应的第二持有状态为有持锁者;如果判断到目标锁没有持锁者,则可以确定目标锁对应的第二持有状态为无持锁者。
作为一种可实施的方式,若确定第二持有状态为有持锁者,则可以确定目标进程当前持有该目标锁,则可以将目标锁对应的第二持有状态更新为无持锁者,并向目标进程反馈第二信息,其中,第二信息用于指示针对目标锁释放锁成功,之后,目标进程可以继续正常运行。基于此,可以实现目标进程通过一次释放申请完成对目标锁的释放,避免目标进程因多次申请目标锁而多次释放目标锁的问题。
作为一种可实施的方式,若确定第二持有状态为无持锁者,则可以向目标进程反馈第二信息,其中,第二信息用于指示对目标锁释放成功,之后,目标进程可以继续正常运行。可以理解的是,若确定第二持有状态为无持锁者,则可以确定目标进程已经没有持有目标锁,既然目标进程已经没有持有目标锁,则可以通过向目标进程反馈用于指示针对目标锁释放锁成功的第二信息的方式,使得目标进程可以继续正常运行。
作为一种可实施的方式,若确定第二持有状态为无持锁者,则可以生成第二告警信息,其中,该第二告警信息用于指示释放未持有的锁。可以理解的是,若确定第二持有状态为无持锁者,则可以确定目标进程在没有持有目标锁的情况下又再次申请释放目标锁,即可以确定目标进程存在重复申请释放锁的情况,因此,可以通过生成第二告警信息的方式指示目标进程申请释放未持有的锁,从而实现对目标进程针对相同锁的重复释放申请的错误进行记录,以便于后续对该错误进行修复。可选地,第二告警信息可以包括记录日志、屏幕提示等,在此不做限定。
步骤S240:在等待所述目标锁被释放的情况下,确定所述目标锁对应的锁性质。
在本实施例中,在确定等待目标锁被释放的情况下,可以确定目标锁对应的锁性质。可选地,目标锁对应的锁性质可以包括自旋锁性质或者互斥锁性质,在此不做限定。
在一些实施方式中,在确定目标锁对应的持有状态为有持有者,且持有者不是目标进程的情况下,可以确定需要等待目标锁被释放,且在等待目标锁被释放的情况下,可以确定目标锁对应的锁性质。
作为一种可实施的方式,在等待目标锁被释放的情况下,可以获取目标锁对应的锁标识,基于锁标识确定目标锁对应的锁性质。例如,若锁标识为第一标识,则可以确定目标锁对应的锁性质为互斥锁性质,若锁标识为第二标识,则可以确定目标锁对应的锁性质为自旋锁性质。
作为又一种可实施的方式,在等待目标锁被释放的情况下,可以获取目标锁的操作方式,基于操作方式确定目标锁对应的锁性质。其中,互斥锁在加锁操作失败时会将线程置于等待状态,而自旋锁在加锁操作失败时会让线程一直处于忙等待状态,两者操作方式不同,因此,可以基于操作方式确定目标锁对应的锁性质为互斥锁性质还是自旋锁性质。
作为再一种可实施的方式,在等待目标锁被释放的情况下,可以获取目标锁的适用场景,基于适用场景确定目标锁对应的锁性质。其中,互斥锁适用于在加锁时间较长或加锁频繁的场景,因此它可以避免线程因等待锁而一直处于阻塞的状态。而自旋锁适用于加锁时间很短或者加锁不频繁的场景,因为它可以避免线程因等待锁而浪费CPU资源,两者适用场景不同,因此,可以基于适用场景确定目标锁对应的锁性质为互斥锁性质还是自旋锁性质。
作为另一种可实施的方式,在等待目标锁被释放的情况下,可以获取目标锁的释放方式,基于释放方式确定目标锁对应的锁性质。其中,互斥锁在释放时需要显式地调用释放函数,自旋锁在释放时可以自动进行解锁操作,两者释放方式不同,因此,可以基于释放方式确定目标锁对应的锁性质为互斥锁性质还是自旋锁性质。
步骤S250:若确定所述锁性质为互斥锁性质,则确定所述目标进程在申请所述目标资源时针对所述中央处理器的占有状态,其中,所述占有状态包括独占状态或者非独占状态,所述目标进程在等待分配所述目标资源的过程中处于休眠状态,所述目标进程在休眠状态下让出中央处理器的调度。
在一些实施方式中,在确定锁性质为互斥锁性质的情况下,可以确定目标进程在申请目标资源时针对中央处理器的占有状态。其中,由于互斥锁的特性,在等锁期间会处于休眠状态,相应目标进程会让出中央处理器的调度,因此,如果确定锁性质为互斥锁性质,可以确定目标进程在申请目标资源时针对中央处理器的占有状态,并在确定占有状态为独占状态时,保持占有状态为独占状态直到将目标资源分配至目标进程,可以实现在对设备运行性能影响可控的前提下,能够消解较复杂锁场景的死锁问题和调度问题,避免因此导致的整机复位(注:死锁问题和调度问题往往会以整机复位方式来被动恢复设备,故障表现为Panic或者Watchdog),提升设备的可靠性,增强产品的竞争力。
在一些实施方式中,在确定锁性质为自旋锁性质的情况下,可以按照目标锁的特性等待目标锁被释放,在确定目标锁被释放的情况下,可以将目标锁的持锁者设置为目标进程。其中,由于自旋锁的特性,在等锁期间会独占CPU,因此,按自旋锁的特性等待目标锁被释放,也可以保持目标进程始终独占CPU,不会造成等锁期间让出CPU调度的情况,从而可以避免死锁的问题。
步骤S260:若确定所述占有状态为独占状态,则保持所述占有状态为独占状态直到将所述目标资源分配至所述目标进程。
其中,步骤S260的具体描述请参阅步骤S130,在此不再赘述。
本申请一实施例提供的资源申请方法,接收目标进程对目标锁的申请,确定目标锁对应的第一持有状态,其中,第一持有状态包括有持锁者和无持锁者,若确定第一持有状态为有持锁者,则确定需要等待目标锁被释放,在等待目标锁被释放的情况下,确定目标锁对应的锁性质,若确定锁性质为互斥锁性质,则确定目标进程在申请目标资源时针对中央处理的占有状态,其中,占有状态包括独占状态或者非独占状态,目标进程在等待分配目标资源的过程中处于休眠状态,目标进程在休眠状态下让出中央处理器的调度,若确定占有状态为独占状态,则保持占有状态为独占状态直到目标资源分配至目标进程。相较于图8所示的资源申请方法,本实施例还限定目标资源为目标锁,在确定需要等待目标锁被释放的情况下,如果确定目标锁对应的锁性质为互斥锁性质,则可以确定目标进程在等待锁释放的过程中会处于休眠状态,因此如果目标进程独占中央处理器,则可以保持目标进程对中央处理器的独占状态,以避免出现死锁的问题。
请参阅图11,图11示出了本申请一实施例提供的资源申请方法的流程示意图。在本实施例中,目标资源为目标锁,下面将针对图11所示的流程进行详细的阐述,所述资源申请方法具体可以包括以下步骤:
步骤S310:接收目标进程对目标资源的申请。
步骤S320:在等待分配所述目标资源给所述目标进程的情况下,确定所述目标进程在申请所述目标资源时针对中央处理器的占有状态,其中,所述占有状态包括独占状态或者非独占状态,所述目标进程在等待分配所述目标资源的过程中处于休眠状态,所述目标进程在休眠状态下让出中央处理器的调度。
步骤S330:若确定所述占有状态为独占状态,则保持所述占有状态为独占状态直到将所述目标资源分配至所述目标进程。
其中,步骤S310-步骤S330的具体描述请参阅步骤S110-步骤S130,在此不再赘述。
步骤S340:若确定所述占有状态为独占状态,则生成第三告警信息,其中,所述第三告警信息用于指示关闭抢占后休眠。
在本实施例中,若确定占有状态为独占状态,则可以生成第三告警信息,其中,该第三告警信息用于指示关闭抢占后休眠。可以理解的是,若确定占有状态为独占状态,则可以确定目标进程在申请目标资源时的状态和等待分配目标资源时的状态存在矛盾,会造成系统卡顿的问题,因此,可以通过生成第三告警信息的方式指示关闭抢占后休眠,从而实现对目标进程针对资源申请的错误进行记录,以便于后续对该错误进行修复。可选地,第三告警信息可以包括记录日志、屏幕提示等,在此不做限定。
本申请一实施例提供的资源申请方法,接收目标进程对目标资源的申请,在等待分配目标资源给目标进程的情况下,确定目标进程在申请目标资源时针对中央处理的占有状态,其中,占有状态包括独占状态或者非独占状态,目标进程在等待分配目标资源的过程中处于休眠状态,目标进程在休眠状态下让出中央处理器的调度,若确定占有状态为独占状态,则保持占有状态为独占状态直到目标资源分配至目标进程,并生成第三告警信息,其中,第三告警信息用于指示关闭抢占后休眠,相较于图8所示的资源申请方法,本实施例还在占有状态为独占状态的情况下生成用于指示关闭抢占后休眠的告警信息,可以对资源申请的错误类型进行记录,提升对错误的修复效率和成功率。
请参阅图12,图12示出了本申请一实施例提供的资源申请方法的流程示意图。在本实施例中,目标资源为目标锁,下面将针对图12所示的流程进行详细的阐述,所述资源申请方法具体可以包括以下步骤:
步骤S410:接收目标进程对目标资源的申请。
步骤S420:在等待分配所述目标资源给所述目标进程的情况下,确定所述目标进程在申请所述目标资源时针对中央处理器的占有状态,其中,所述占有状态包括独占状态或者非独占状态,所述目标进程在等待分配所述目标资源的过程中处于休眠状态,所述目标进程在休眠状态下让出中央处理器的调度。
步骤S430:若确定所述占有状态为独占状态,则保持所述占有状态为独占状态直到将所述目标资源分配至所述目标进程。
其中,步骤S410-步骤S430的具体描述请参阅步骤S110-步骤S130,在此不再赘述。
步骤S440:若确定所述占有状态为非独占状态,则保持所述占有状态为非独占状态直到将所述目标资源分配至所述目标进程。
在本实施例中,若确定占有状态为非独占状态,则可以保持占有状态为非独占状态直到将目标资源分配至目标进程。可以理解的是,若确定占有状态为非独占状态,则可以确定目标进程在申请目标资源时的状态和等待分配目标资源时的状态不存在矛盾,不会造成系统卡顿的问题,因此,可以保持占有状态为非独占状态直到将目标资源分配至目标进程。
本申请一实施例提供的资源申请方法,接收目标进程对目标资源的申请,在等待分配目标资源给目标进程的情况下,确定目标进程在申请目标资源时针对中央处理的占有状态,其中,占有状态包括独占状态或者非独占状态,目标进程在等待分配目标资源的过程中处于休眠状态,目标进程在休眠状态下让出中央处理器的调度,若确定占有状态为独占状态,则保持占有状态为独占状态直到目标资源分配至目标进程,若确定占有状态为非独占状态,则保持占有状态为非独占状态直到目标资源分配至目标进程。相较于图1所示的资源申请方法,本实施例还在占有状态为非独占状态的情况下,确定目标进程对中央处理器的占有状态不会造成系统崩溃或死机的问题,可以保持非独占状态直到目标资源分配至目标进程,以降低电子设备的功耗和提升电子设备的资源利用率。
其中,如图13所示,在目标资源为目标锁的情况下,可以包括以下步骤:
1、目标进程开始运行。
2、目标进程需要访问受目标锁保护的一个共享资源。
3、目标进程调用系统接口[申请锁]。
4、判断目标锁有没有持锁者。
5、如果目标锁没有持锁者:
a)设置持锁者为目标进程。
b)反馈给目标进程“申请锁成功”的信息。
6、如果目标锁有持锁者:
a)判断持锁者是不是目标进程。
b)如果持锁者是目标进程,产生一次“申请已持有的锁”告警(示例:记录日志、屏幕提示)。
c)反馈给目标进程“申请持锁成功”的信息。
7、目标进程正常访问共享资源。
8、访问完成之后,目标进程调用系统接口[释放锁]。
9、判断目标锁有没有持锁者。
10、如果目标锁有持锁者:
a)设置持锁者为“无”。
b)反馈给目标进程“释放锁成功”的信息。
c)目标进程继续正常运行。
11、如果目标锁没有持锁者:
a)产生一次“释放未申请的锁”告警(示例:记录日志、屏幕提示)。
b)反馈给目标进程“释放锁成功”的信息。
c)目标进程继续正常运行。
12、在步骤6.a中(判断持锁者是不是目标进程),如果持锁者不是目标进程,反馈给目标进程“要等锁释放”的信息。
13、判断目标锁的性质,是自旋锁还是互斥锁。
14、如果目标锁是自旋锁:目标进程就按目标锁的特性(注:自旋锁的特性是等锁期间会独占CPU)来等待锁释放。
15、如果目标锁是互斥锁:
a)判断目标进程是不是“独占CPU”的状态。
b)如果目标进程不是“独占CPU”的状态,目标进程就按目标锁的特性(注:互斥锁的特性是等锁期间会休眠)来等待锁释放。
c)如果目标进程是“独占CPU”的状态,产生一次“关闭抢占后休眠”告警(示例:记录日志、屏幕提示)
d)目标进程保持“独占CPU”的状态等待锁释放。
其中,如图14所示,在将本申请实施例所提供的方案应用于多次申请同一个锁的场景时,可以包括以下步骤:
1、目标进程开始运行。
2、目标进程需要访问受目标锁保护的一个共享资源。
3、目标进程调用系统接口[申请锁]。
4、判断目标锁有没有持锁者。
5、如果目标锁没有持锁者,设置持锁者为目标进程。
6、反馈给目标进程“申请锁成功”的信息。
7、目标进程正常访问共享资源。
8、目标进程继续正常运行。
9、目标进程需要访问受目标锁保护的另一个共享资源。
10、目标进程调用系统接口[申请锁]。
11、判断目标锁有没有持锁者。
12、如果目标锁有持锁者,判断持锁者是不是目标进程。
13、如果持锁者是目标进程,反馈给目标进程“申请锁成功”的信息。
14、目标进程正常访问共享资源。
15、目标进程继续正常运行。
其中,如图15所示,在多次申请同一个锁后还有多次释放同一个锁,可以包括以下步骤:
1、目标进程访问完了共享资源之后,调用系统接口[释放锁]。
2、判断目标锁有没有持锁者。
3、如果目标锁有持锁者,设置持锁者为“无”。
4、反馈给目标进程“释放锁成功”的信息。
5、目标进程继续正常运行。
6、目标进程访问完了另一共享资源之后,调用系统接口[释放锁]。
7、判断目标锁有没有持锁者。
8、如果目标锁没有持锁者,反馈给目标进程“释放锁成功”的信息。
9、目标进程继续正常运行。
其中,如图16所示,在将本申请实施例所提供的方案应用于持有自旋锁后申请互斥锁的场景时,可以包括以下步骤:
1、目标进程开始运行。
2、目标进程需要访问受自旋锁保护的一个共享资源。
3、目标进程调用系统接口[申请锁]。
4、判断自旋锁有没有持锁者。
5、如果自旋锁没有持锁者,设置持锁者为目标进程。
6、反馈给目标进程“申请锁成功”的信息。
7、由于自旋锁的特性,目标进程会独占CPU,即,所在CPU只服务于该进程,分配到该CPU上的其它进程都无法运行。
8、目标进程正常访问共享资源。
9、目标进程继续正常运行。
10、目标进程需要访问受互斥锁保护的一个共享资源。
11、目标进程调用系统接口[申请锁]。
12、判断互斥锁有没有持锁者。
13、如果互斥锁有持锁者,反馈给目标进程“要等锁释放”的信息。
14、判断目标进程是不是独占CPU状态。
15、如果目标进程是独占CPU状态,继续以独占CPU方式,等待互斥锁的释放。
16、直到互斥锁被释放,反馈给目标进程“申请锁成功”的信息。
17、目标进程正常访问共享资源。
18、目标进程继续正常运行。
其中,如图17所示,在将本申请实施例所提供的方案应用于中断处理后申请互斥锁的场景时,可以包括以下步骤:
1、中断处理开始运行。
2、中断处理独占CPU。
3、中断处理需要访问受互斥锁保护的一个共享资源。
4、中断处理调用系统接口[申请锁]。
5、判断互斥锁有没有持锁者。
6、如果互斥锁有持锁者,反馈给中断处理“要等锁释放”的信息。
7、判断中断处理是不是独占CPU状态。
8、如果中断处理是独占CPU状态,继续以独占CPU方式,等待互斥锁的释放。
9、直到互斥锁被释放,反馈给目标进程“申请锁成功”的信息。
10、中断处理正常访问共享资源
11、中断处理继续正常运行。
请参阅图18,图18示出了本申请一实施例提供的资源申请装置的模块框图。下面将针对图18所示的框图进行阐述,所述资源申请装置200包括:申请接收模块210、占有状态确定模块220以及状态控制模块230,其中:
申请接收模块210,用于接收目标进程对目标资源的申请。
占有状态确定模块220,用于在等待分配所述目标资源给所述目标进程的情况下,确定所述目标进程在申请所述目标资源时针对中央处理器的占有状态,其中,所述占有状态包括独占状态或者非独占状态,所述目标进程在等待分配所述目标资源的过程中处于休眠状态,所述目标进程在休眠状态下让出中央处理器的调度。
进一步地,所述目标资源为目标锁,所述占有状态确定模块220包括:锁性质确定子模块和占有状态确定子模块,其中:
锁性质确定子模块,用于在等待所述目标锁被释放的情况下,确定所述目标锁对应的锁性质。
占有状态确定子模块,用于若确定所述锁性质为互斥锁性质,则确定所述目标进程在申请所述目标资源时针对所述中央处理器的占有状态。
进一步地,所述占有状态确定模块220还包括:第一锁释放等待子模块和持锁者确定子模块,其中:
第一锁释放等待子模块,用于若确定所述锁性质为自旋锁性质,则按照所述目标锁的特性等待所述目标锁被释放。
持锁者确定子模块,用于在确定所述目标锁被释放的情况下,将所述目标锁的持锁者设置为所述目标进程。
进一步地,所述占有状态确定模块220还包括:第一持有状态确定子模块和第二锁释放等待子模块,其中:
第一持有状态确定子模块,用于确定所述目标锁对应的第一持有状态,其中,所述第一持有状态包括有持锁者或者无持锁者。
第二锁释放等待子模块,用于若确定所述第一持有状态为有持锁者,则确定需要等待所述目标锁被释放。
进一步地,所述第二锁释放等待子模块包括:目标持锁者确定单元和第二锁释放等待单元,其中:
目标持锁者确定单元,用于若确定所述第一持有状态为有持锁者,则确定所述目标锁对应的目标持锁者。
第二锁释放等待单元,用于若确定所述目标持锁者不是所述目标进程,则确定需要等待所述目标锁被释放。
进一步地,所述第二锁释放等待子模块还包括:第一告警信息生成单元,其中:
第一告警信息生成单元,用于若确定所述目标持锁者是所述目标进程,则生成第一告警信息,其中,所述第一告警信息用于指示申请已持有的锁。
进一步地,所述第二锁释放等待子模块还包括:第一信息反馈单元,其中:
第一信息反馈单元,用于若确定所述目标持锁者是所述目标进程,则向所述目标进程反馈第一信息,其中,所述第一信息用于指示针对所述目标锁申请锁成功。
进一步地,所述第二锁释放等待子模块还包括:释放请求接收单元、第二持有状态确定单元以及第二信息反馈单元,其中:
释放请求接收单元,用于接收所述目标进程针对所述目标锁的释放请求。
第二持有状态确定单元,用于确定所述目标锁对应的第二持有状态,其中,所述第二持有状态包括有持锁者或者无持锁者。
第二信息反馈单元,用于若确定所述第二持有状态为有持锁者,则将所述目标锁对应的第二持有状态更新为无持锁者,并向所述目标进程反馈第二信息,其中,所述第二信息用于指示针对所述目标锁释放锁成功。
进一步地,所述第二锁释放等待子模块还包括:第二告警信息生成单元,其中:
第二告警信息生成单元,用于若确定所述第二持有状态为无持锁者,则向所述目标进程反馈所述第二信息,并生成第二告警信息,其中,所述第二告警信息用于指示释放未持有的锁。
状态控制模块230,用于若确定所述占有状态为独占状态,则保持所述占有状态为独占状态直到将所述目标资源分配至所述目标进程。
进一步地,所述资源申请装置200还包括:第三告警信息生成模块,其中:
第三告警信息生成模块,用于若确定所述占有状态为独占状态,则生成第三告警信息,其中,所述第三告警信息用于指示关闭抢占后休眠。
进一步地,所述资源申请装置200还包括:占有状态保持模块,其中:
占有状态保持模块,用于若确定所述占有状态为非独占状态,则保持所述占有状态为非独占状态直到将所述目标资源分配至所述目标进程。
进一步地,所述资源申请装置200还包括:第一独占状态确定模块和第二独占状态确定模块,其中:
第一独占状态确定模块,用于若所述目标进程在申请所述目标资源时持有自旋锁,则确定所述目标进程在申请所述目标资源时针对所述中央处理器的占有状态为独占状态。
第二独占状态确定模块,用于若所述目标进程为中断服务程序,则确定所述目标进程在申请所述目标资源时针对所述中央处理器的占有状态为独占状态。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述装置和模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,模块相互之间的耦合可以是电性,机械或其它形式的耦合。
另外,在本申请各个实施例中的各功能模块可以集成在一个处理模块中,也可以是各个模块单独物理存在,也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。
请参阅图19,其示出了本申请实施例提供的一种电子设备100的结构框图。该电子设备100可以是智能手机、平板电脑、电子书等能够运行应用程序的电子设备。本申请中的电子设备100可以包括一个或多个如下部件:处理器110、存储器120以及一个或多个应用程序,其中一个或多个应用程序可以被存储在存储器120中并被配置为由一个或多个处理器110执行,一个或多个程序配置用于执行如前述方法实施例所描述的方法。
其中,处理器110可以包括一个或者多个处理核。处理器110利用各种接口和线路连接整个电子设备100内的各个部分,通过运行或执行存储在存储器120内的指令、程序、代码集或指令集,以及调用存储在存储器120内的数据,执行电子设备100的各种功能和处理数据。可选地,处理器110可以采用数字信号处理(Digital Signal Processing,DSP)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)、可编程逻辑阵列(ProgrammableLogic Array,PLA)中的至少一种硬件形式来实现。处理器110可集成中央处理器(CentralProcessing Unit,CPU)、图形处理器(Graphics Processing Unit,GPU)和调制解调器等中的一种或几种的组合。其中,CPU主要处理操作系统、用户界面和应用程序等;GPU用于负责待显示内容的渲染和绘制;调制解调器用于处理无线通信。可以理解的是,上述调制解调器也可以不集成到处理器110中,单独通过一块通信芯片进行实现。
存储器120可以包括随机存储器(Random Access Memory,RAM),也可以包括只读存储器(Read-Only Memory)。存储器120可用于存储指令、程序、代码、代码集或指令集。存储器120可包括存储程序区和存储数据区,其中,存储程序区可存储用于实现操作系统的指令、用于实现功能的指令(比如触摸功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等。存储数据区还可以存储电子设备100在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。
请参阅图20,其示出了本申请实施例提供的一种计算机可读存储介质的结构框图。该计算机可读介质300中存储有程序代码,所述程序代码可被处理器调用执行上述方法实施例中所描述的方法。
计算机可读存储介质300可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。可选地,计算机可读存储介质300包括非易失性计算机可读介质(non-transitory computer-readable storage medium)。计算机可读存储介质300具有执行上述方法中的任何方法步骤的程序代码310的存储空间。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码310可以例如以适当形式进行压缩。
综上所述,本申请实施例提供的资源申请方法、装置、电子设备以及存储介质,接收目标进程对目标资源的申请,在等待分配目标资源给目标进程的情况下,确定目标进程在申请目标资源时针对中央处理器的占有状态,其中,该占有状态包括独占状态或者非独占状态,目标进程在等待分配目标资源的过程中处于休眠状态,目标进程在休眠状态下让出中央处理器的调度,若确定占有状态为独占状态,则保持占有状态为独占状态直到将目标资源分配至目标进程,从而通过针对带有休眠行为和让出中央处理器的调度的资源申请场景,在识别到进程是独占中央处理器的状态时,继续保持独占中央处理器的状态,可以避免系统崩溃或死机的问题。
最后应说明的是:以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不驱使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (15)

1.一种资源申请方法,其特征在于,所述方法包括:
接收目标进程对目标资源的申请;
在等待分配所述目标资源给所述目标进程的情况下,确定所述目标进程在申请所述目标资源时针对中央处理器的占有状态,其中,所述占有状态包括独占状态或者非独占状态,所述目标进程在等待分配所述目标资源的过程中处于休眠状态,所述目标进程在休眠状态下让出中央处理器的调度;
若确定所述占有状态为独占状态,则保持所述占有状态为独占状态直到将所述目标资源分配至所述目标进程。
2.根据权利要求1所述的方法,其特征在于,所述目标资源为目标锁,所述在等待分配所述目标资源给所述目标进程的情况下,确定所述目标进程在申请所述目标资源时针对中央处理器的占有状态,包括:
在等待所述目标锁被释放的情况下,确定所述目标锁对应的锁性质;
若确定所述锁性质为互斥锁性质,则确定所述目标进程在申请所述目标资源时针对所述中央处理器的占有状态。
3.根据权利要求2所述的方法,其特征在于,所述方法还包括:
若确定所述锁性质为自旋锁性质,则按照所述目标锁的特性等待所述目标锁被释放;
在确定所述目标锁被释放的情况下,将所述目标锁的持锁者设置为所述目标进程。
4.根据权利要求2所述的方法,其特征在于,在所述在等待所述目标锁被释放的情况下,确定所述目标锁对应的锁性质之前,还包括:
确定所述目标锁对应的第一持有状态,其中,所述第一持有状态包括有持锁者或者无持锁者;
若确定所述第一持有状态为有持锁者,则确定需要等待所述目标锁被释放。
5.根据权利要求4所述的方法,其特征在于,所述若确定所述第一持有状态为有持锁者,则确定需要等待所述目标锁被释放,包括:
若确定所述第一持有状态为有持锁者,则确定所述目标锁对应的目标持锁者;
若确定所述目标持锁者不是所述目标进程,则确定需要等待所述目标锁被释放。
6.根据权利要求5所述的方法,其特征在于,所述方法还包括:
若确定所述目标持锁者是所述目标进程,则生成第一告警信息,其中,所述第一告警信息用于指示申请已持有的锁。
7.根据权利要求5所述的方法,其特征在于,所述方法还包括:
若确定所述目标持锁者是所述目标进程,则向所述目标进程反馈第一信息,其中,所述第一信息用于指示针对所述目标锁申请锁成功。
8.根据权利要求7所述的方法,其特征在于,在所述若确定所述目标持锁者是所述目标进程,则向所述目标进程反馈第一信息之后,还包括:
接收所述目标进程针对所述目标锁的释放请求;
确定所述目标锁对应的第二持有状态,其中,所述第二持有状态包括有持锁者或者无持锁者;
若确定所述第二持有状态为有持锁者,则将所述目标锁对应的第二持有状态更新为无持锁者,并向所述目标进程反馈第二信息,其中,所述第二信息用于指示针对所述目标锁释放锁成功。
9.根据权利要求8所述的方法,其特征在于,所述方法还包括:
若确定所述第二持有状态为无持锁者,则向所述目标进程反馈所述第二信息,并生成第二告警信息,其中,所述第二告警信息用于指示释放未持有的锁。
10.根据权利要求1-9任一项所述的方法,其特征在于,所述方法还包括:
若确定所述占有状态为独占状态,则生成第三告警信息,其中,所述第三告警信息用于指示关闭抢占后休眠。
11.根据权利要求1-9任一项所述的方法,其特征在于,所述方法还包括:
若确定所述占有状态为非独占状态,则保持所述占有状态为非独占状态直到将所述目标资源分配至所述目标进程。
12.根据权利要求1-9任一项所述的方法,其特征在于,所述确定所述目标进程在申请所述目标资源时针对中央处理器的占有状态,包括:
若所述目标进程在申请所述目标资源时持有自旋锁,则确定所述目标进程在申请所述目标资源时针对所述中央处理器的占有状态为独占状态;或者
若所述目标进程为中断服务程序,则确定所述目标进程在申请所述目标资源时针对所述中央处理器的占有状态为独占状态。
13.一种资源申请装置,其特征在于,所述装置包括:
申请接收模块,用于接收目标进程对目标资源的申请;
占有状态确定模块,用于在等待分配所述目标资源给所述目标进程的情况下,确定所述目标进程在申请所述目标资源时针对中央处理器的占有状态,其中,所述占有状态包括独占状态或者非独占状态,所述目标进程在等待分配所述目标资源的过程中处于休眠状态,所述目标进程在休眠状态下让出中央处理器的调度;
状态控制模块,用于若确定所述占有状态为独占状态,则保持所述占有状态为独占状态直到将所述目标资源分配至所述目标进程。
14.一种电子设备,其特征在于,包括存储器和处理器,所述存储器耦接到所述处理器,所述存储器存储指令,当所述指令由所述处理器执行时所述处理器执行如权利要求1-12任一项所述的方法。
15.一种计算机可读取存储介质,其特征在于,所述计算机可读取存储介质中存储有程序代码,所述程序代码可被处理器调用执行如权利要求1-12任一项所述的方法。
CN202311500125.6A 2023-11-10 2023-11-10 资源申请方法、装置、电子设备以及存储介质 Pending CN117453413A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311500125.6A CN117453413A (zh) 2023-11-10 2023-11-10 资源申请方法、装置、电子设备以及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311500125.6A CN117453413A (zh) 2023-11-10 2023-11-10 资源申请方法、装置、电子设备以及存储介质

Publications (1)

Publication Number Publication Date
CN117453413A true CN117453413A (zh) 2024-01-26

Family

ID=89596482

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311500125.6A Pending CN117453413A (zh) 2023-11-10 2023-11-10 资源申请方法、装置、电子设备以及存储介质

Country Status (1)

Country Link
CN (1) CN117453413A (zh)

Similar Documents

Publication Publication Date Title
US5448732A (en) Multiprocessor system and process synchronization method therefor
KR100911796B1 (ko) 하드웨어 지원을 갖는 다중 프로세서 및 다중 스레드 안전메시지 큐
CN110489213B (zh) 一种任务处理方法及处理装置、计算机系统
US7734833B2 (en) Method for scheduling operations called by a task on a real-time or non-real time processor
US20020078121A1 (en) Real-time scheduler
CN108885559B (zh) 在多个处理器之间快速转移工作负载
US9311138B2 (en) System management interrupt handling for multi-core processors
CN112416546A (zh) 多任务调度方法、电子装置和计算机存储介质
WO2010067492A1 (ja) マルチプロセッサシステム及びその排他制御の調停方法
CN113010275B (zh) 一种中断处理方法和装置
CN111857993B (zh) 一种内核态调用用户态函数的方法
US7103631B1 (en) Symmetric multi-processor system
JP2004288162A (ja) 同期タスクを利用したオペレーティングシステムアーキテクチャ
CN111897637B (zh) 作业调度方法、装置、主机及存储介质
WO2022001303A1 (zh) 一种锁管理方法、装置及设备
CN111324432A (zh) 处理器调度方法、装置、服务器及存储介质
CN109766168B (zh) 任务调度方法和装置、存储介质以及计算设备
WO2023241307A1 (zh) 管理线程的方法及装置
US11301304B2 (en) Method and apparatus for managing kernel services in multi-core system
US7748003B2 (en) Hard real-time response
CN117453413A (zh) 资源申请方法、装置、电子设备以及存储介质
JP5678347B2 (ja) Itシステムの構成方法、そのコンピュータプログラムおよびitシステム
JP2693916B2 (ja) タスクスケジュール方法
US11461134B2 (en) Apparatus and method for deferral scheduling of tasks for operating system on multi-core processor
CN115951987A (zh) 一种存储系统中多线程的任务执行方法、装置以及介质

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