A method and system for locking control of resources based on a workflow system

Abstract

The application discloses a method and system for locking control of resources based on a workflow system, and the method comprises the following steps: determining the number of workflows and the number of resources to be locked according to the obtained tasks; judging whether the current locking share is less than 100% according to the locking share and the resource identifier of any resource to be locked; if the current locking share of any resource to be locked is less than 100%, locking the any resource according to the current locking share and updating the locking identifier; if the current locking share of any resource to be locked is greater than or equal to 100%, judging that the locking share is insufficient, and retrying the locking of the any resource. The system comprises four parts of a workflow and a number of resources to be locked determination module, a judgment module, a resource locking module and a retry locking module. Through the application, the resource utilization rate and the resource control efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of computer resource control technology, and in particular to a method and system for locking and controlling resources based on a workflow system. Background Technology

[0002] With the development of computer software products, their resource consumption in the deployment environment is increasing. Especially when users or threads concurrently access one or a group of resources, resource utilization can become extremely high, potentially leading to memory overflow, bandwidth exhaustion, and other problems. Therefore, how to control software resources is a crucial technical issue.

[0003] The current method for controlling computer resources is usually to wait when resource usage is overloaded, until the previous resource is released before the next resource can be accessed.

[0004] However, current methods for controlling computer resources rely solely on passive waiting, especially when there are many resources passively waiting, and there are no corresponding processing methods, resulting in low resource control efficiency and low resource utilization. Summary of the Invention

[0005] This application provides a method and system for locking and controlling resources based on a workflow system, in order to solve the problems of low resource utilization and low resource control efficiency in existing resource control methods.

[0006] To address the aforementioned technical problems, the embodiments of this application disclose the following technical solutions:

[0007] A method for locking and controlling resources based on a workflow system, the method comprising:

[0008] Based on the acquired tasks, determine the number of workflows and the number of resources to be locked, and define the locking share of any workflow for any resource to be locked as P_TRn, where n is a natural number;

[0009] Based on the locking share and resource identifier of any resource to be locked, determine whether the current locking share is <100%;

[0010] If the current lock share of any of the resources to be locked is less than 100%, lock the resource according to the current lock share and update the lock identifier;

[0011] If the current lock share of any resource to be locked is ≥100%, it is determined that the lock share is insufficient, and the locking of any resource is retried.

[0012] Optionally, before determining whether the current locked share is less than 100% based on any of the shares to be locked and the resource identifier, the method further includes:

[0013] The database is queried based on the workflow identifier and resource identifier to determine whether the resource lock record already exists in the database.

[0014] If the resource lock record already exists in the database, determine whether the locking flag in the resource lock record is TRUE;

[0015] If the locking flag in the resource lock record is TRUE, it is determined that the current workflow has successfully locked the current resource;

[0016] If the locking flag in the resource lock record is not TRUE, proceed directly to the next step: determine whether the current locking share is <100% based on the locking share and resource identifier of any resource to be locked;

[0017] If the resource lock record does not exist in the database, generate and save the data record for the current resource lock.

[0018] Optionally, the method for retrying locking any of the resources after determining that the lock share is insufficient includes:

[0019] Define the maximum lock wait time as MAX_WAIT_TIME, the initial retry lock interval as P_TIME0, and the minimum retry lock interval as MIN_P_TIME;

[0020] Calculate the time difference between the current time and the time of the first locking;

[0021] Based on the time difference, the first retry lock interval is calculated using the formula P1_TIMEn=MAX(MIN_P_TIM,P_TIME0–P_TIME0*(DIFF_TIME / MAX_WAIT_TIME)), where P1_TIMEn is the first retry lock interval, DIFF_TIME is the time difference between the current time and the first lock time, MAX_WAIT_TIME is the set maximum lock waiting time, and MIN_P_TIME is the set minimum retry lock interval.

[0022] The workflow retry locking the resource according to the first next retry locking time interval;

[0023] After the first next retry locking time interval is reached, the time difference between the current time and the first locking time is recalculated until any workflow has completed locking any resource.

[0024] Optionally, when the first locking time of multiple workflows is the same, the priority weight P_WEIGHT of any workflow is specified according to the acquired command, wherein the priority weight P_WEIGHT of any workflow satisfies: 1≤P_WEIGHT≤10, P_WEIGHT is a natural number, and the smaller P_WEIGHT is, the higher the priority.

[0025] Based on the priority weight P_WEIGHT, the second next retry locking interval for each workflow is calculated using the formula P2_TIME=MAX(MIN_P_TIME,P_TIME0–P_TIME0*(DIFF_TIME / MAX_WAIT_TIME))-(10-P_WEIGHT).

[0026] Multiple workflows sequentially retry locking any of the resources in ascending order of the second next retry locking interval.

[0027] Optionally, when the first retry lock time interval of multiple workflows is greater than the set maximum lock waiting time, the priority weight P_WEIGHT of any workflow is specified according to the obtained command, wherein the priority weight P_WEIGHT of any workflow satisfies: 1≤P_WEIGHT≤10, P_WEIGHT is a natural number, and the smaller P_WEIGHT is, the higher the priority.

[0028] Based on the priority weight P_WEIGHT, the third next retry locking interval for each workflow is calculated using the formula P3_TIME=MIN_P_TIME-(10-P_WEIGHT).

[0029] Multiple workflows sequentially retry locking any of the resources according to the order of the third next retry locking time interval from smallest to largest or from largest to smallest.

[0030] Optionally, when multiple workflows have the same priority weight, the CPU computing resources are retried and locked sequentially according to the order in which each workflow acquires them.

[0031] Optionally, the method further includes:

[0032] When any workflow finishes its task, delete the data record of the workflow locking any resource to be locked.

[0033] A system for locking and controlling resources based on a workflow system, the system comprising:

[0034] The workflow and number of locked resources determination module is used to determine the number of workflows and the number of locked resources based on the acquired tasks. The locking share of any workflow for any locked resource is defined as P_TRn, where n is a natural number.

[0035] The first judgment module is used to determine whether the current locking share is less than 100% based on the locking share and resource identifier of any resource to be locked;

[0036] The resource locking module is used to lock any resource according to its current locking share and update the locking identifier when the current locking share of any resource to be locked is less than 100%.

[0037] The retry locking mode is used to retry locking any resource when the current locking share of any resource to be locked is ≥100%.

[0038] Optionally, the system further includes:

[0039] The second judgment module is used to query the database based on the workflow identifier and resource identifier to determine whether the resource lock record already exists in the database. If the resource lock record already exists in the database, the third judgment module is started. If the resource lock record does not exist in the database, the data record generation module is started.

[0040] The third judgment module is used to determine whether the locking flag in the resource lock record is TRUE when the resource lock record already exists in the database. If the locking flag in the resource lock record is TRUE, it is determined that the current workflow has successfully locked the current resource; otherwise, the first judgment module is started.

[0041] The data record generation module is used to generate and save the current resource lock data record when the resource lock record does not exist in the database.

[0042] Optionally, the system further includes:

[0043] The deletion module is used to delete the data records of any workflow locking any resource to be locked after the workflow finishes its task.

[0044] The technical solutions provided by the embodiments of this application may include the following beneficial effects:

[0045] This application provides a method for locking resources based on a workflow system. The method first determines the number of workflows and the number of resources to be locked based on the acquired tasks. Then, it determines the current locking percentage. If the locking percentage is less than 100%, the resource can continue to be locked; otherwise, the locking process is retried. This embodiment achieves proactive resource locking control by judging the resource locking percentage and executing different resource locking methods based on different percentages. Compared to the passive waiting in existing technologies, this embodiment enables the system to maximize resource utilization under safe loads, which is beneficial for improving resource control efficiency and resource utilization.

[0046] When the lock allocation is insufficient, this embodiment utilizes relevant lock interval parameters and calculates the first retry lock interval to retry locking any resource. The calculated first retry lock interval is used as a period for polling and scheduling the workflow. This workflow-based lock retry method can fully utilize system resources for concurrent operations without excessive resource consumption, avoiding high resource utilization and accelerating workflow execution efficiency. This embodiment also sets corresponding resource retry lock methods for further resource consumption scenarios, such as workflows having the same initial lock time and the first retry lock interval exceeding the set maximum lock waiting time. This helps to further solve the problem of excessive resource preemption during concurrent access, thereby improving resource utilization and resource control efficiency.

[0047] Furthermore, this embodiment also checks whether the resource lock record exists in the database, making full use of existing database resources for resource locking, which helps improve resource control efficiency. It also updates the data records in a timely manner, providing a basis for subsequent resource locking, which further helps improve resource control efficiency.

[0048] This application also provides a system for locking resources based on a workflow system. This system mainly includes four parts: a workflow and a module for determining the number of resources to be locked, a judgment module, a resource locking module, and a retry locking module. By setting the judgment module, resource locking module, and retry locking module, the resource locking share can be determined, and different resource locking methods can be executed according to different shares, thereby achieving active resource locking control. Compared to the passive waiting in the prior art, this embodiment enables the system to maximize the utilization of system resources under safe load, which is beneficial to improving resource control efficiency and resource utilization.

[0049] This embodiment also includes a deletion module, which can promptly delete relevant data records after the workflow task is completed, thereby releasing resource space and improving resource utilization.

[0050] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0051] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0052] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 A flowchart illustrating a method for locking resources based on a workflow system, provided in an embodiment of this application;

[0054] Figure 2 This is a schematic diagram of a system for locking and controlling resources based on a workflow system, provided as an embodiment of this application. Detailed Implementation

[0055] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of this application.

[0056] To better understand this application, the embodiments of this application will be explained in detail below with reference to the accompanying drawings.

[0057] Example 1

[0058] See Figure 1 , Figure 1 This is a flowchart illustrating a method for locking resources based on a workflow system, provided in an embodiment of this application. Figure 1 As can be seen, the method for locking resources based on the workflow system in this embodiment mainly includes the following processes:

[0059] S1: Based on the acquired tasks, determine the number of workflows and the number of resources to be locked.

[0060] The locking share of any workflow for any resource to be locked is defined as P_TRn, where n is a natural number. This embodiment employs a resource lock mechanism. A resource lock is a mechanism in a workflow system that controls access to one or a group of resources to be operated on by different workflows; it is a method of resource protection. For example, when backing up multiple virtual machines simultaneously to a backup storage pool, to prevent a large amount of I / O from consuming backup network bandwidth, it is necessary to lock the backup storage pool resources. The resource lock mechanism controls the number of virtual machine backup tasks executed simultaneously to protect network bandwidth. Resources to be operated on can be locked repeatedly, but the number of times a resource or group of resources is locked needs to be controlled. This is achieved by setting a locking share for one or a group of resources in different workflows according to a percentage. When the resource locking share is exhausted, subsequent workflows will no longer be able to lock that resource.

[0061] The data structures used in this embodiment include: a resource identifier to be locked, used as a unique identifier for the resource, generally an ID; a workflow identifier, used to mark the workflow that needs to lock the resource, generally an ID; a locking share, used to represent the percentage of the resource that the workflow wants to control; a successful locking identifier, used to mark whether the workflow has successfully locked the resource; and the first locking time, used to record the time when the workflow first attempted to lock the resource.

[0062] See also Figure 1 As can be seen, after determining the number of workflows and the number of resources to be locked, step S6 is executed: based on the locking share and resource identifier of any resource to be locked, determine whether the current locking share is <100%.

[0063] Furthermore, steps S2-S5 are included before step S6. Specifically, step S2: Query the database based on the workflow identifier and resource identifier to determine whether the resource lock record already exists in the database.

[0064] If the resource lock record already exists in the database, proceed to step S3: determine whether the locking flag in the resource lock record is TRUE.

[0065] If the locking flag in the resource lock record is TRUE, proceed to step S4: determine if the current workflow has successfully locked the current resource;

[0066] If the locking flag in the resource lock record is not TRUE, proceed directly to step S6: Determine whether the current locking share is <100% based on the locking share and resource identifier of any resource to be locked.

[0067] If the resource lock record does not exist in the database, proceed to step S5: Generate and save the data record for the current resource lock.

[0068] According to the data structure in step S1 above, when the workflow needs to perform a locking operation on the resource, a data record will be generated. In this embodiment, the data record is saved to the storage medium, which includes, but is not limited to: database, local file and memory.

[0069] The data record format includes: workflow identifier, resource identifier to be requested, lock share, lock success identifier, and lock time.

[0070] From steps S2-S5 above, assuming the first workflow t1 starts executing and requests resource R1, the locking share of t1 on R1 is defined as P_TR1 according to business needs. Based on the unique identifier of resource R1, the stored resource lock records are queried, and records with a successful locking flag of TRUE are selected. The locking shares of all records are summed to obtain SUM_R1. The database records are queried based on the workflow identifier and the resource R1 identifier. If the resource lock record exists in the database and the locking flag is TRUE, then workflow t1 has successfully locked resource R1. If the resource lock record exists in the database and the locking flag is FALSE, then the previous locking attempt failed. If P_TR1 + SUM_R1 < 100%, the successful locking flag is updated to TRUE, indicating successful locking this time. If P_TR1 + SUM_R1 ≥ 100%, then the locking share of resource R1 is insufficient to lock it, and the process waits for the next locking attempt. If the resource lock record does not exist in the database's data records, then determine whether P_TR1+SUM_R1<100%. If so, generate a data record with the data structure format in step S1, where the lock acquisition success indicator is TRUE, indicating that the lock acquisition was successful. If P_TR1+SUM_R1≥100%, meaning that the lock share of resource R1 is insufficient and cannot be locked, skip this step and wait for the next lock acquisition.

[0071] By employing steps S2-S5 above, existing database resources can be fully utilized for resource locking, which helps improve resource control efficiency. Timely updates to data records provide a basis for subsequent resource locking, further enhancing resource control efficiency.

[0072] See also Figure 1 It can be seen that when determining whether the current locking share is <100%, if the current locking share of any resource to be locked is <100%, step S7 is executed: lock any resource according to the current locking share and update the locking identifier.

[0073] By updating the locking flag, the data record information can be fully utilized in the subsequent resource locking judgment process, which helps to improve resource locking efficiency and resource control efficiency.

[0074] If the current lock share of any resource to be locked is ≥100%, it is determined that the lock share is insufficient, and step S8 is executed: retry locking any resource.

[0075] Further, step S8 includes the following process:

[0076] S801: Define the maximum lock wait time as MAX_WAIT_TIME, the initial retry lock interval as P_TIME0, and the minimum retry lock interval as MIN_P_TIME.

[0077] The maximum lock wait time can be set to 1 hour, the initial retry lock interval can be set to 30,000 milliseconds, and the minimum retry lock interval can be set to 100 milliseconds.

[0078] S802: Calculate the time difference between the current time and the first locking time.

[0079] DIFF_TIME = CUR_TIME - Tn, where DIFF_TIME is the time difference between the current time and the first locking time, CUR_TIME is the current time, and Tn is the first locking time.

[0080] S803: Based on the time difference, the first retry lock time interval is calculated using the formula P1_TIMEn=MAX(MIN_P_TIM,P_TIME0–P_TIME0*(DIFF_TIME / MAX_WAIT_TIME)).

[0081] Where P1_TIMEn is the first retry lock interval, DIFF_TIME is the time difference between the current time and the first lock acquisition time, MAX_WAIT_TIME is the maximum lock waiting time set, and MIN_P_TIME is the minimum retry lock interval set.

[0082] S804: Any workflow may retry locking any resource based on the first next retry lock interval.

[0083] S805: After the first retry lock interval is reached, return to recalculate the time difference between the current time and the first lock time, until any workflow has completed locking any resource.

[0084] That is, after the retry locking time interval calculated in step S803 is reached, the process returns to step S802 with this time interval as the period, and the workflow is scheduled to be executed in a polling manner with this retry locking time interval.

[0085] As can be seen from steps S201-S805 above, according to the method in this embodiment, the value of P1_TIMEn will decrease over time, meaning that the workflow scheduling cycle will become shorter and shorter over time, and the scheduling frequency will increase. Workflows executed earlier will request locks more frequently, and the probability of obtaining a lock and executing it within the same time frame is also higher, thereby avoiding resource consumption and improving data control efficiency.

[0086] Furthermore, when multiple workflows have the same initial locking time, step S811 is executed: based on the acquired command, the priority weight P_WEIGHT of any workflow is specified. The priority weight P_WEIGHT of any workflow satisfies: 1 ≤ P_WEIGHT ≤ 10, where P_WEIGHT is a natural number, and the smaller the P_WEIGHT, the higher the priority.

[0087] S812: Based on the priority weight P_WEIGHT, the second next retry locking interval for each workflow is calculated using the formula P2_TIME=MAX(MIN_P_TIME,P_TIME0–P_TIME0*(DIFF_TIME / MAX_WAIT_TIME))-(10-P_WEIGHT).

[0088] S813: Multiple workflows will retry locking any resource in ascending order of the second next retry lock interval.

[0089] In this embodiment, the smaller P2_TIME is, the higher the priority weight of the workflow and the higher its call frequency. This method can further distinguish the resource utilization rate of multiple workflows with the same first locking time, thereby avoiding excessive resource consumption and improving resource control efficiency.

[0090] Furthermore, when the first retry lock time interval of multiple workflows is greater than the set maximum lock waiting time, step S831 is executed: according to the obtained command, the priority weight P_WEIGHT of any workflow is specified, wherein the priority weight P_WEIGHT of any workflow satisfies: 1≤P_WEIGHT≤10, P_WEIGHT is a natural number, and the smaller P_WEIGHT is, the higher the priority.

[0091] When the first retry lock time interval of multiple workflows is greater than the set maximum lock waiting time, as can be seen from the formula in step S803, MAX(MIN_P_TIME,P_TIME-P_TIME*(DIFF_TIME / MAX_WAIT_TIME))=MIN_P_TIME, that is, the scheduling period of all workflows to be executed becomes MIN_P_TIME.

[0092] S832: Based on the priority weight P_WEIGHT, the third next retry locking interval for each workflow is calculated using the formula P3_TIME=MIN_P_TIME-(10-P_WEIGHT);

[0093] S833: Multiple workflows will retry locking any resource in ascending or descending order of the third next retry lock interval.

[0094] As shown in step S833, the time intervals for the third and next retry locking are sorted by size. Multiple workflows can then retry locking any resource sequentially according to this sorting. The order is not fixed; it doesn't matter whether the retry times are from largest to smallest or smallest. As long as the retry locking times are staggered, excessive resource consumption can be avoided. Through steps S831-S833, the scheduling cycles of different workflows can differ according to their weights, thus differentiating the probability of each workflow acquiring a lock and achieving effective resource control.

[0095] Furthermore, when multiple workflows have the same priority weight in step S812 or step S832, each workflow acquires the CPU computing resource in the order in which it acquires the resource, and then retryes locking the resource. That is, the workflow that acquires the CPU computing resource first retryes locking the resource first.

[0096] Through the above steps, this embodiment can cover most scenarios in practical applications during the retry locking process, which is beneficial to improving resource control efficiency and resource utilization.

[0097] The method in this embodiment further includes step S9: after any workflow finishes its task, delete the data record of any workflow locking any resource to be locked.

[0098] By promptly deleting unnecessary data records, system resources can be used where they are more needed, thus improving the utilization rate of system resources.

[0099] Example 2

[0100] exist Figure 1 Based on the illustrated embodiment, see also Figure 2 , Figure 2 This is a schematic diagram of a system for locking and controlling resources based on a workflow system, provided as an embodiment of this application.

[0101] Depend on Figure 2 As can be seen, the system for locking resources based on the workflow system in this embodiment mainly includes four parts: a workflow and a module for determining the number of resources to be locked, a judgment module, a resource locking module, and a retry locking module.

[0102] The module for determining the number of workflows and resources to be locked is used to determine the number of workflows and resources to be locked based on the acquired tasks, and defines the locking share of any workflow for any resource to be locked as P_TRn, where n is a natural number; the first judgment module is used to determine whether the current locking share is <100% based on the locking share and resource identifier of any resource to be locked; the resource locking module is used to lock any resource according to the current locking share and update the locking identifier when the current locking share of any resource to be locked is <100%; and the retry locking module is used to retry locking any resource when the current locking share of any resource to be locked is ≥100%.

[0103] Furthermore, the system also includes: a second judgment module, a third judgment module, and a data record generation module. The second judgment module queries the database based on the workflow identifier and resource identifier to determine if the resource lock record already exists in the database. If the resource lock record already exists, the third judgment module is activated; otherwise, the data record generation module is activated. The third judgment module, when the resource lock record already exists in the database, checks if the locking flag in the resource lock record is TRUE. If the locking flag is TRUE, it determines that the current workflow has successfully locked the current resource; otherwise, the first judgment module is activated. The data record generation module generates and saves the current resource lock's data record when the resource lock record does not exist in the database.

[0104] The system also includes a deletion module, which deletes the data records of any workflow locking any resource to be locked after any workflow finishes its task.

[0105] This embodiment describes the working principle and method of a workflow system for locking and controlling resources. Figure 1 The embodiments shown have been described in detail and will not be repeated here.

[0106] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for locking and controlling resources based on a workflow system, characterized in that, The method includes: Based on the acquired tasks, determine the number of workflows and the number of resources to be locked, and define the locking share of any workflow for any resource to be locked as P_TRn, where n is a natural number; Based on the locking share and resource identifier of any resource to be locked, determine whether the current locking share is less than 100%; If the current lock share of any of the resources to be locked is less than 100%, lock the resource according to the current lock share and update the lock identifier; If the current lock share of any resource to be locked is ≥100%, it is determined that the lock share is insufficient, and the locking of any resource is retried. Before determining whether the current locked share is less than 100% based on any of the shares to be locked and the resource identifier, the method further includes: The database is queried based on the workflow identifier and resource identifier to determine whether the resource lock record already exists in the database. If the resource lock record already exists in the database, determine whether the locking flag in the resource lock record is TRUE; If the locking flag in the resource lock record is TRUE, it is determined that the current workflow has successfully locked the current resource; If the locking flag in the resource lock record is not TRUE, proceed directly to the next step: determine whether the current locking share is less than 100% based on the locking share and resource identifier of any resource to be locked; If the resource lock record does not exist in the database, generate and save the data record for the current resource lock.

2. The method for locking and controlling resources based on a workflow system according to claim 1, characterized in that, A method for retrying locking any of the resources after determining that the lock share is insufficient includes: Define the maximum lock wait time as MAX_WAIT_TIME, the initial retry lock interval as P_TIME0, and the minimum retry lock interval as MIN_P_TIME; Calculate the time difference between the current time and the time of the first locking; Based on the time difference, the first next retry lock interval is calculated using the formula P1_TIMEn=MAX(MIN_P_TIM,P_TIME0–P_TIME0*(DIFF_TIME / MAX_WAIT_TIME)), where P1_TIMEn is the first next retry lock interval, DIFF_TIME is the time difference between the current time and the first lock time, MAX_WAIT_TIME is the set maximum lock waiting time, and MIN_P_TIME is the set minimum retry lock interval. The workflow retry locking the resource according to the first next retry locking time interval; After the first next retry locking time interval is reached, the time difference between the current time and the first locking time is recalculated until any workflow has completed locking any resource.

3. The method for locking and controlling resources based on a workflow system according to claim 2, characterized in that, When multiple workflows have the same initial locking time, the priority weight P_WEIGHT of any workflow is specified according to the acquired command. The priority weight P_WEIGHT of any workflow satisfies: 1≤P_WEIGHT≤10, P_WEIGHT is a natural number, and the smaller P_WEIGHT is, the higher the priority. Based on the priority weight P_WEIGHT, the second next retry locking interval for each workflow is calculated using the formula P2_TIME = MAX(MIN_P_TIME, P_TIME0 – P_TIME0 * (DIFF_TIME / MAX_WAIT_TIME)) - (10 - P_WEIGHT). Multiple workflows sequentially retry locking any of the resources in ascending order of the second next retry locking interval.

4. The method for locking and controlling resources based on a workflow system according to claim 2, characterized in that, When the first retry lock time interval of multiple workflows is greater than the set maximum lock waiting time, the priority weight P_WEIGHT of any workflow is specified according to the obtained command, wherein the priority weight P_WEIGHT of any workflow satisfies: 1≤P_WEIGHT≤10, P_WEIGHT is a natural number, and the smaller P_WEIGHT is, the higher the priority. Based on the priority weight P_WEIGHT, the third next retry locking interval for each workflow is calculated using the formula P3_TIME=MIN_P_TIME - (10 - P_WEIGHT). Multiple workflows sequentially retry locking any of the resources according to the order of the third next retry locking time interval from smallest to largest or from largest to smallest.

5. A method for locking and controlling resources based on a workflow system according to claim 3 or 4, characterized in that, When multiple workflows have the same priority weight, the CPU computing resources are retried and locked in the order in which each workflow acquires them.

6. A method for locking and controlling resources based on a workflow system according to any one of claims 1-4, characterized in that, The method further includes: When any workflow finishes its task, delete the data record of the workflow locking any resource to be locked.

7. A system for locking and controlling resources based on a workflow system, characterized in that, The system includes: The workflow and number of locked resources determination module is used to determine the number of workflows and the number of locked resources based on the acquired tasks. The locking share of any workflow for any locked resource is defined as P_TRn, where n is a natural number. The first judgment module is used to determine whether the current locking share is less than 100% based on the locking share and resource identifier of any resource to be locked; The resource locking module is used to lock any resource according to its current locking share and update the locking identifier when the current locking share of any resource to be locked is less than 100%. The retry locking mode is used to retry locking any resource when the current locking share of any resource to be locked is ≥100%. The system also includes: The second judgment module is used to query the database based on the workflow identifier and resource identifier to determine whether the resource lock record already exists in the database. If the resource lock record already exists in the database, the third judgment module is started. If the resource lock record does not exist in the database, the data record generation module is started. The third judgment module is used to determine whether the locking flag in the resource lock record is TRUE when the resource lock record already exists in the database. If the locking flag in the resource lock record is TRUE, it is determined that the current workflow has successfully locked the current resource; otherwise, the first judgment module is started. The data record generation module is used to generate and save the current resource lock data record when the resource lock record does not exist in the database.

8. A system for locking and controlling resources based on a workflow system according to claim 7, characterized in that, The system also includes: The deletion module is used to delete the data records of any workflow locking any resource to be locked after the workflow finishes its task.

Images