A shared resource processing method and device, electronic equipment and storage medium
By identifying and allocating shared resource needs, the thread blocking problem was solved, server response efficiency was improved, and the rational allocation and utilization of shared resources were achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- INSPUR SUZHOU INTELLIGENT TECH CO LTD
- Filing Date
- 2024-12-31
- Publication Date
- 2026-05-29
AI Technical Summary
In a server environment, when there are many parallel threads, existing technologies often result in a large number of threads entering a blocked state due to improper management of shared resources, which affects the server's response efficiency to user requests.
By obtaining the shared resource allocation request of the thread to be executed and the current shared resource semaphore, it is determined whether the thread meets the execution conditions. If the conditions are met, the shared resources required for the first execution phase are allocated, and the semaphore is updated to reserve the resources required for the remaining execution phases, so as to avoid thread blocking.
This effectively avoids resource shortages during thread execution, reduces thread blocking, and improves the server's response efficiency to user requests.
Smart Images
Figure CN119806841B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device and storage medium for processing shared resources. Background Technology
[0002] In a server environment, when a client sends a business request to the server, the server typically creates threads to handle these requests. These threads acquire shared resources from the server to respond to the business requests. These shared resources include memory resources and the number of processor cores.
[0003] In related technologies, a shared resource semaphore is usually set, and the semaphore count is set to the total number of shared resources. When a thread acquires a shared resource, the semaphore count is decremented by 1. When a thread releases a shared resource, the semaphore count is incremented by 1. When the count is zero, the thread stops initiating shared resource request operations.
[0004] However, since a single complex thread needs different amounts of shared resources at different stages of the entire request-response process, and in order to ensure the utilization of shared resources, the system limits the thread to only obtaining a portion of the shared resources needed for the current execution stage each time. When there are many parallel threads on the server, multiple complex threads may be unable to obtain the remaining shared resources during execution, resulting in a large number of threads entering a blocked state at the same time, which is not conducive to ensuring the server's response efficiency to user requests. Summary of the Invention
[0005] This application provides a shared resource processing method, apparatus, electronic device, and storage medium to solve the defects of related technologies, such as a large number of threads entering a blocked state at the same time, which is not conducive to ensuring the server's response efficiency to user requests.
[0006] The first aspect of this application provides a method for processing shared resources, including:
[0007] Obtain the shared resource allocation request and the current shared resource semaphore of the thread to be executed; wherein, the current shared resource semaphore represents the remaining amount of shared resource;
[0008] Based on the relationship between the total demand for shared resources represented by the shared resource allocation request of the thread to be executed and the current shared resource semaphore, it is determined whether the thread to be executed currently meets the execution conditions;
[0009] If it is determined that the thread to be executed currently meets the execution conditions, in response to the shared resource allocation request, the shared resources required for the first execution stage are allocated to the thread to be executed; wherein, the thread to be executed includes multiple execution stages;
[0010] The current shared resource semaphore is updated to the difference between the total shared resource requirement and the current shared resource semaphore, in order to reserve the shared resources required for the remaining execution phase of the thread to be executed.
[0011] In an optional implementation, the method further includes:
[0012] If it is determined that the thread to be executed does not currently meet the execution conditions, it is determined whether the thread to be executed is allowed to wait based on the thread configuration information represented by the shared resource allocation request of the thread to be executed.
[0013] If it is determined that the thread to be executed is allowed to wait, the thread to be executed is designated as a waiting thread, and the thread to be executed enters a blocked state.
[0014] Based on the total shared resource requirements of the waiting threads, create the waiting thread node corresponding to the waiting thread;
[0015] The waiting thread node is added to a preset waiting list to wait for a wake-up event outside the preset shared resource mutex lock range;
[0016] When any of the waiting thread nodes in the preset waiting list receives the wake-up event, analyze the reason for the wake-up of the waiting thread node;
[0017] If the reason for waking up the waiting thread node is that the execution conditions are met, the waiting thread node is restored to a non-blocking state and the step of allocating the shared resources required for the first execution phase to the waiting thread in response to the shared resource allocation request is executed.
[0018] If the reason for waking up the waiting thread node is a timeout, the waiting thread node is removed from the preset waiting list.
[0019] In an optional implementation, the method further includes:
[0020] Obtain the waiting time threshold for each waiting thread node in the preset waiting list;
[0021] For any of the waiting thread nodes, when the waiting time of the waiting thread node in the preset waiting list exceeds the waiting time threshold, a wake-up event for the waiting thread node is generated.
[0022] In an optional implementation, the method further includes:
[0023] When the current shared resource semaphore increases, the preset waiting list is traversed to determine whether there is a waiting thread node in the preset waiting list that currently meets the execution conditions;
[0024] If it is determined that any of the waiting thread nodes currently meets the execution conditions, a wake-up event for that waiting thread node is generated.
[0025] In an optional implementation, the method further includes:
[0026] When the current shared resource semaphore increases, it is determined whether the head waiting thread node in the preset waiting list currently meets the execution conditions;
[0027] If it is determined that the head waiting thread node currently meets the execution conditions, a wake-up event for the head waiting thread node is generated;
[0028] If it is determined that the current execution conditions of the head waiting thread node are not met, the wake-up event will not be generated.
[0029] In one optional implementation, adding the waiting thread node to a preset waiting list includes:
[0030] The waiting thread node is added as a tail waiting thread node to the end of the preset waiting list so that the waiting thread nodes in the preset waiting list are awakened in the order they were added.
[0031] In an optional implementation, the method further includes:
[0032] When any thread completes all execution phases, it releases all shared resources acquired during the execution process.
[0033] The current shared resource semaphore is updated to the sum of the thread's shared resource release amount and the current shared resource semaphore, so that the current shared resource semaphore increases.
[0034] A second aspect of this application provides a shared resource processing apparatus, comprising:
[0035] The acquisition module is used to acquire the shared resource allocation request and the current shared resource semaphore of the thread to be executed; wherein, the current shared resource semaphore represents the remaining amount of shared resource;
[0036] The judgment module is used to determine whether the thread to be executed currently meets the execution conditions based on the relationship between the total demand for shared resources represented by the shared resource allocation request of the thread to be executed and the current shared resource semaphore.
[0037] The allocation module is configured to, in response to the shared resource allocation request, allocate shared resources required for the first execution stage to the thread to be executed, provided that the thread to be executed currently meets the execution conditions; wherein the thread to be executed includes multiple execution stages;
[0038] The update module is used to update the current shared resource semaphore to the difference between the total demand for shared resources and the current shared resource semaphore, so as to reserve the shared resources required by the thread to be executed for the remaining execution phase.
[0039] A third aspect of this application provides an electronic device, comprising: at least one processor and a memory;
[0040] The memory stores computer-executed instructions;
[0041] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method described in the first aspect above and various possible designs of the first aspect.
[0042] The fourth aspect of this application provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the method described in the first aspect above and various possible designs of the first aspect.
[0043] The fifth aspect of this application provides a computer program product including computer instructions for causing a computer to perform the methods described in the first aspect above and various possible designs of the first aspect.
[0044] The technical solution of this application has the following advantages:
[0045] This application provides a shared resource processing method, apparatus, electronic device, and storage medium. The method includes: acquiring a shared resource allocation request from a thread to be executed and a current shared resource semaphore; wherein the current shared resource semaphore represents the remaining amount of shared resources; determining whether the thread to be executed currently meets the execution conditions based on the relationship between the total shared resource requirement represented by the shared resource allocation request and the current shared resource semaphore; if it is determined that the thread to be executed currently meets the execution conditions, allocating shared resources required for the first execution stage to the thread to be executed in response to the shared resource allocation request; wherein the thread to be executed includes multiple execution stages; updating the current shared resource semaphore to the difference between the total shared resource requirement and the current shared resource semaphore, so as to reserve shared resources required for the remaining execution stages of the thread to be executed. The method provided above, by reducing the current shared resource semaphore in advance according to the total shared resource requirement of the thread to be executed, reserves all the shared resources required by the thread to be executed, avoiding a shortage of shared resources during the execution of the thread to be executed, thereby preventing a large number of threads to be executed from entering a blocked state simultaneously, and thus ensuring the server's response efficiency to user requests. Attached Figure Description
[0046] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.
[0047] Figure 1 This is a schematic diagram of the structure of the shared resource processing system on which the embodiments of this application are based;
[0048] Figure 2 A flowchart illustrating the shared resource processing method provided in this application embodiment;
[0049] Figure 3 A flowchart illustrating an exemplary shared resource processing method provided in this application embodiment;
[0050] Figure 4 A flowchart illustrating another exemplary shared resource processing method provided in this application embodiment;
[0051] Figure 5 This is a schematic diagram of the structure of the shared resource processing device provided in the embodiments of this application;
[0052] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0053] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the present disclosure in any way, but rather to illustrate the concepts of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0054] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0055] Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. In the following descriptions of embodiments, "a plurality of" means two or more, unless otherwise explicitly defined.
[0056] In multithreaded programming, a semaphore is a counter used to control access to shared resources by multiple threads. It can be used to implement thread synchronization. The typical usage is to set the semaphore counter to the total number of shareable resources. When a thread acquires the semaphore, the counter is decremented by 1; when a thread releases the semaphore, the counter is incremented by 1. When the counter reaches zero, the semaphore acquisition operation will fail or block. Both Windows and Linux operating systems provide semaphores using this implementation method.
[0057] However, sometimes such semaphores are insufficient. Suppose there are 10 shared resources, thread A needs 5 resources, and thread B needs 8 resources. If they acquire resources one by one (waiting for the signal), A may get 4 resources (4 successful waits), and B may get 6 resources (6 successful waits). When they continue to acquire (wait), they will both get blocked and will not be able to be woken up due to insufficient resources.
[0058] To address the aforementioned issues, this application provides a shared resource processing method, apparatus, electronic device, and storage medium. The method includes: acquiring a shared resource allocation request from a thread to be executed and a current shared resource semaphore; wherein the current shared resource semaphore represents the remaining amount of shared resources; determining whether the thread to be executed currently meets execution conditions based on the relationship between the total shared resource requirement represented by the shared resource allocation request and the current shared resource semaphore; if the thread to be executed currently meets execution conditions, allocating shared resources required for the first execution stage to the thread to be executed in response to the shared resource allocation request; wherein the thread to be executed includes multiple execution stages; updating the current shared resource semaphore to the difference between the total shared resource requirement and the current shared resource semaphore, to reserve shared resources required for the remaining execution stages of the thread to be executed. The method provided above, by reducing the current shared resource semaphore in advance based on the total shared resource requirement of the thread to be executed, reserves all shared resources required by the thread to be executed, avoiding a shortage of shared resources during the thread's operation, and preventing a large number of threads to be executed from simultaneously entering a blocked state, thereby ensuring the server's response efficiency to user requests.
[0059] The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.
[0060] First, the structure of the shared resource processing system on which this application is based will be described:
[0061] The shared resource processing method, apparatus, electronic device, and storage medium provided in this application are suitable for allocating shared resources to threads to be executed, including multiple asynchronous tasks. Figure 1 The diagram shows the structure of the shared resource processing system based on the embodiments of this application, which mainly includes a shared resource pool, threads to be executed, and a shared resource processing device. The shared resource processing device is used to count the current remaining amount of shared resources in the shared resource pool to obtain the current shared resource semaphore. When a thread to be executed makes a shared resource allocation request, the device performs corresponding shared resource allocation processing on the thread to be executed according to the current shared resource semaphore.
[0062] This application provides a shared resource processing method for allocating shared resources to threads that include multiple asynchronous tasks. The execution subject of this application is an electronic device, such as a server, desktop computer, laptop computer, tablet computer, or other electronic devices that can be used to allocate shared resources.
[0063] like Figure 2 The diagram shown is a flowchart illustrating a shared resource processing method provided in an embodiment of this application. The method includes:
[0064] Step 201: Obtain the shared resource allocation request and current shared resource semaphore of the thread to be executed.
[0065] The current shared resource semaphore represents the remaining amount of shared resources. The initial value of the current shared resource semaphore, initiatelCount, is equal to the maximum count value, maximumCount, which is equal to the total amount of shared resources in the shared resource pool.
[0066] Specifically, the system can obtain shared resource allocation requests issued by threads waiting to be executed, and at the same time, obtain the current shared resource semaphore, which can intuitively reflect the remaining number of shared resources available for allocation in the current system.
[0067] Step 202: Based on the relationship between the total demand for shared resources represented by the shared resource allocation request of the thread to be executed and the current shared resource semaphore, determine whether the thread to be executed currently meets the execution conditions.
[0068] Specifically, if the total demand for shared resources is less than or equal to the current shared resource semaphore, then the thread to be executed is determined to currently meet the execution conditions; otherwise, the thread to be executed is determined to currently not meet the execution conditions.
[0069] Step 203: If it is determined that the thread to be executed currently meets the execution conditions, in response to the shared resource allocation request, the shared resources required for the first execution phase are allocated to the thread to be executed.
[0070] The thread to be executed includes multiple execution stages.
[0071] It should be noted that the thread to be executed includes multiple asynchronous tasks, each corresponding to a different execution phase. Taking the thread to be executed as processing user data query requests as an example, the asynchronous tasks are, in sequence, parsing the data query request data packet, performing a database query operation based on the request content, generating response content based on the database query results, and returning the response content to the client. These four asynchronous tasks correspond to four execution phases, and the amount of shared resources required for each execution phase is different.
[0072] Step 204: Update the current shared resource semaphore to the difference between the total shared resource requirement and the current shared resource semaphore, so as to reserve the shared resources required by the remaining execution phase of the thread to be executed.
[0073] For example, with a current shared resource semaphore of 10 and a total shared resource requirement of 6, the updated current shared resource semaphore equals 4. Even if the thread to be executed requires 1 shared resource in the first execution phase (i.e., only 1 shared resource is allocated to the thread to be executed at present), since the thread to be executed requires 5 shared resources in the remaining execution phases, to prevent the shared resources from being allocated to other threads during its execution, thus preventing the thread from being unable to acquire the corresponding number of shared resources in the remaining execution phases, the current shared resource semaphore is reduced in advance. This reserves the shared resources required by the thread to be executed in the remaining execution phases, ensuring that the thread that has already started execution can complete all execution phases normally without entering a blocked state midway.
[0074] Based on the above embodiments, in order to further achieve the rational allocation of shared resources, as an implementable approach, in one embodiment, the method further includes:
[0075] Step 301: If it is determined that the thread to be executed does not currently meet the execution conditions, determine whether the thread to be executed is allowed to wait based on the thread configuration information represented by the shared resource allocation request of the thread to be executed.
[0076] Step 302: If it is determined that the thread to be executed is allowed to wait, the thread to be executed is set as a waiting thread and the thread to be executed enters a blocked state;
[0077] Step 303: Based on the total shared resource requirements of the waiting threads, create the waiting thread node corresponding to each waiting thread.
[0078] Step 304: Add the waiting thread node to the preset waiting list so that it can wait for the wake-up event outside the preset shared resource mutex lock range;
[0079] Step 305: When any waiting thread node in the preset waiting list receives a wake-up event, analyze the reason for the wake-up of that waiting thread node;
[0080] Step 306: If the reason for waking up the waiting thread node is that the execution conditions are met, restore the waiting thread node to a non-blocking state of the thread to be executed, and execute the step of allocating the shared resources required for the first execution phase to the thread to be executed in response to the shared resource allocation request.
[0081] Step 307: If the reason for waking up the waiting thread node is a timeout, remove the waiting thread node from the preset waiting list.
[0082] The thread configuration information includes at least a waiting time threshold. If the waiting time threshold is 0, the thread to be executed is not allowed to wait; if the waiting time threshold is greater than 0, the thread to be executed is allowed to wait. The pre-defined shared resource mutex lock range indicates that the thread to be executed releases the shared resource mutex lock, allowing other threads to request and acquire the shared resource.
[0083] Specifically, in one embodiment, the waiting thread node can be added as the tail waiting thread node to the tail of the preset waiting list so that the waiting thread nodes in the preset waiting list are awakened in the order of addition.
[0084] For example, such as Figure 3 The diagram illustrates an exemplary shared resource processing method provided in this application embodiment, which uses wake-up events to suspend and wake up waiting threads. When the remaining available count (current shared resource semaphore) is less than the required number (needSingle, total shared resource demand), it is determined that the thread to be executed does not currently meet the execution conditions. Next, it checks if the waiting time threshold is 0 to determine if the thread is allowed to wait. That is, when the thread's required resources exceed the currently available resources, the thread's configuration information is further examined to determine if the thread can wait. If the waiting time threshold is 0, meaning the thread is not allowed to wait, failure is returned directly. In other words, when it is determined that the thread is not allowed to wait, no blocking operation is performed; instead, the thread's attempt to acquire resources is terminated directly. If the waiting time threshold is not 0 (meaning the thread is allowed to wait), a WaitingThreadNode object (waiting thread node) is created and recorded as "myself". The waiting thread node is used to record its waiting state and related information. After creating the `WaitingThreadNode` object, `myself` is added to the tail of the linked list. The head and tail of the linked list are set. Then, outside the scope of the preset shared resource mutex, the `awakenEvent` signal (wake-up event) is waited for. When a thread is woken up, it waits for the thread node in the linked list to receive the wake-up event, and then performs subsequent judgments to further analyze the reason for the wake-up of the waiting thread node. If the thread successfully obtains the signal after being woken up, that is, the reason for the wake-up is that the execution condition is met, it means that `value` is more than the required number `needSingle`, so `value` is updated = `value - needSingle`, and success is returned. If the thread fails to obtain the signal, it is determined that the reason for its wake-up is a timeout, so `myself` is removed from the waiting linked list, that is, the waiting thread node is removed from the preset waiting linked list, and failure is returned.
[0085] Among them, such as Figure 3 The process shown can be implemented using the wait method, with wait configuration parameters including needSingle and timeout.
[0086] Accordingly, in one embodiment, the waiting time threshold of each waiting thread node in the preset waiting list can be obtained; for any waiting thread node, when the waiting time of the waiting thread node in the preset waiting list exceeds the waiting time threshold, a wake-up event of the waiting thread node is generated.
[0087] Specifically, to prevent threads from waiting indefinitely, when the waiting time of a certain waiting thread node exceeds its waiting time threshold, a wake-up event is generated for that waiting thread node. The wake-up event is used to notify the system to process the waiting thread. For example, when thread A times out, a wake-up event for thread A is generated, enabling subsequent processes to handle the timeout of thread A. Timeout handling includes operations such as removing thread A from the waiting list and recording a timeout in the log.
[0088] Specifically, in one embodiment, if any waiting thread node times out, the thread's resource requirements can be re-examined to determine whether the thread can continue execution by adjusting the requirements (total shared resource requirements). For example, if a thread originally requires 10 memory blocks, but after a timeout, it can be checked whether the number of memory blocks required can be reduced to utilize the currently available resources to continue executing part of the task, such as reducing memory usage by decreasing the thread's data processing precision.
[0089] Furthermore, thread timeout events can be logged to the system log, including the thread identifier, the type of resource being waited for, and the timeout duration. This helps technical personnel troubleshoot and perform performance analysis. For example, logging a network communication thread's timeout while waiting for network port resources allows for subsequent analysis to determine whether the timeout is due to network configuration issues or unreasonable resource requirements of the thread itself. When thread timeout events reach a certain frequency or severity, a system alarm is triggered, enabling technical personnel to take timely measures to prevent further deterioration of the system fault.
[0090] Specifically, in one embodiment, when any thread completes all execution phases, it releases all shared resources acquired during the execution process; and updates the current shared resource semaphore to the sum of the thread's shared resource release amount and the current shared resource semaphore, so that the current shared resource semaphore increases.
[0091] Specifically, when a thread releases a shared resource, the current shared resource semaphore Value is updated = Value + single, representing the specified number of shared resources released by the thread. Here, the thread's released shared resource amount single can be equal to the thread's total shared resource requirement needSingle.
[0092] Specifically, in one embodiment, when the wake-up model is in efficient mode, when the current shared resource semaphore increases, the preset waiting list is traversed to determine whether there is a waiting thread node in the preset waiting list that currently meets the execution conditions; if it is determined that any waiting thread node currently meets the execution conditions, a wake-up event for that waiting thread node is generated.
[0093] Specifically, when the current shared resource semaphore increases, the preset waiting list is traversed from head to tail. When the traversal reaches the waiting thread node that currently meets the execution conditions, the traversal is paused and a wake-up event for that waiting thread node is generated.
[0094] Specifically, in one embodiment, when the wake-up model is in sequential mode, when the current shared resource semaphore increases, it is determined whether the head waiting thread node in the preset waiting list currently meets the execution conditions; if it is determined that the head waiting thread node currently meets the execution conditions, a wake-up event for the head waiting thread node is generated; if it is determined that the head waiting thread node currently does not meet the execution conditions, no wake-up event is generated.
[0095] For example, such as Figure 4 The diagram illustrates another exemplary shared resource processing method provided in this application. First, when any single semaphore is released, the semaphore's value is incremented by single. The first node in the preset waiting list (the head waiting thread node) is set as the current waiting thread. It is determined whether the head waiting thread node in the preset waiting list currently meets the execution condition, i.e., whether the total shared resource requirement of the head waiting thread node, needSingle, is less than or equal to the updated value. If so, the head waiting thread node is determined to meet the execution condition, and value is further updated to value = value - needSingle. The waiting thread is removed from the preset waiting list, and a wake-up event is generated to wake it up. It is further determined whether there are any other waiting thread nodes in the preset waiting list. If so, the next waiting thread node is set as the current waiting thread, and the above steps are repeated. If the head waiting thread node does not currently meet the execution condition, the wake-up mode (type) is further determined. If the wake-up mode is sequential, the process ends directly, i.e., no wake-up event is generated. If the wake-up mode is high-efficiency mode, then it is further determined whether there are still waiting thread nodes in the preset waiting list. If there are, then the next waiting thread node is taken as the current waiting thread, and the preset waiting list is traversed from head to tail until the waiting thread node that meets the execution conditions or the tail node of the preset waiting list is found.
[0096] Among them, such as Figure 4The process shown can be implemented using the POST method, and the POST configuration parameters include single.
[0097] The shared resource processing method provided in this application obtains the shared resource allocation request of the thread to be executed and the current shared resource semaphore; wherein the current shared resource semaphore represents the remaining amount of shared resources; based on the relationship between the total shared resource requirement represented by the shared resource allocation request of the thread to be executed and the current shared resource semaphore, it is determined whether the thread to be executed currently meets the execution conditions; if it is determined that the thread to be executed currently meets the execution conditions, in response to the shared resource allocation request, the shared resources required for the first execution stage are allocated to the thread to be executed; wherein the thread to be executed includes multiple execution stages; the current shared resource semaphore is updated to the difference between the total shared resource requirement and the current shared resource semaphore, so as to reserve the shared resources required for the remaining execution stages of the thread to be executed. The method provided by the above scheme, by reducing the current shared resource semaphore in advance according to the total shared resource requirement of the thread to be executed, reserves all the shared resources required by the thread to be executed, avoids the situation of shared resource shortage during the execution of the thread to be executed, and avoids a large number of threads to be executed entering a blocked state at the same time, thereby ensuring the server's response efficiency to user requests. By using mutexes and events, multiple semaphore values can be acquired at once. That is, the semaphore is implemented using basic mutexes and events, supporting all operating systems and exhibiting excellent cross-platform compatibility. Furthermore, the acquisition and release of semaphores in this embodiment employ functions (wait and post) similar to those used in system semaphores, resulting in low learning, development, and maintenance costs.
[0098] This application provides a shared resource processing apparatus for executing the shared resource processing method provided in the above embodiments.
[0099] like Figure 5 The diagram shown is a structural schematic of a shared resource processing device provided in an embodiment of this application. The shared resource processing device 50 includes: an acquisition module 501, a judgment module 502, an allocation module 503, and an update module 504.
[0100] The system includes the following modules: an acquisition module for acquiring the shared resource allocation request and the current shared resource semaphore of the thread to be executed; the current shared resource semaphore represents the remaining amount of shared resources; a judgment module for determining whether the thread to be executed currently meets the execution conditions based on the relationship between the total shared resource requirement represented by the shared resource allocation request and the current shared resource semaphore; an allocation module for allocating shared resources required for the first execution stage of the thread to be executed in response to the shared resource allocation request, provided that the thread to be executed currently meets the execution conditions; the thread to be executed includes multiple execution stages; and an update module for updating the current shared resource semaphore to the difference between the total shared resource requirement and the current shared resource semaphore, in order to reserve shared resources required for the remaining execution stages of the thread to be executed.
[0101] Regarding the shared resource processing device in this embodiment, the specific methods by which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated here.
[0102] The shared resource processing apparatus provided in this application embodiment is used to execute the shared resource processing method provided in the above embodiment. Its implementation method and principle are the same, and will not be described again.
[0103] This application provides an electronic device for executing the shared resource processing method provided in the above embodiments.
[0104] like Figure 6 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this application. The electronic device 60 includes at least one processor 61 and a memory 62.
[0105] The memory stores computer-executable instructions; at least one processor executes the computer-executable instructions stored in the memory, causing the at least one processor to perform the shared resource processing method provided in the above embodiments.
[0106] The electronic device provided in this application embodiment is used to execute the shared resource processing method provided in the above embodiment. Its implementation method and principle are the same, and will not be described again.
[0107] This application provides a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, it implements the shared resource processing method provided in any of the above embodiments.
[0108] The storage medium containing computer-executable instructions provided in this application embodiment can be used to store computer-executable instructions for the shared resource processing method provided in the foregoing embodiments. Its implementation method and principle are the same, and will not be described again.
[0109] This application provides a computer program product, including computer instructions, which are used to cause a computer to execute the shared resource processing method provided in the foregoing embodiments.
[0110] The computer program product provided in this application embodiment can be used to execute the computer instructions of the shared resource processing method provided in the foregoing embodiment. Its implementation method and principle are the same, and will not be described again.
[0111] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0112] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0113] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.
[0114] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0115] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the present invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.
[0116] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is merely an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0117] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A method for processing shared resources, characterized in that, include: Obtain the shared resource allocation request and the current shared resource semaphore of the thread to be executed; wherein, the current shared resource semaphore represents the remaining amount of shared resource; Based on the relationship between the total demand for shared resources represented by the shared resource allocation request of the thread to be executed and the current shared resource semaphore, it is determined whether the thread to be executed currently meets the execution conditions; If it is determined that the thread to be executed currently meets the execution conditions, in response to the shared resource allocation request, the shared resources required for the first execution stage are allocated to the thread to be executed; wherein, the thread to be executed includes multiple execution stages; The current shared resource semaphore is updated to the difference between the total demand for shared resources and the current shared resource semaphore, so as to reserve the shared resources required for the remaining execution phase of the thread to be executed; If it is determined that the thread to be executed does not currently meet the execution conditions, it is determined whether the thread to be executed is allowed to wait based on the thread configuration information represented by the shared resource allocation request of the thread to be executed. If it is determined that the thread to be executed is allowed to wait, the thread to be executed is designated as a waiting thread, and the thread to be executed enters a blocked state. Based on the total shared resource requirements of the waiting threads, create the waiting thread node corresponding to the waiting thread; The waiting thread node is added to a preset waiting list to wait for a wake-up event outside the preset shared resource mutex lock range; When any of the waiting thread nodes in the preset waiting list receives the wake-up event, the reason for the wake-up of the waiting thread node is analyzed.
2. The method according to claim 1, characterized in that, The method further includes: If the reason for waking up the waiting thread node is that the execution conditions are met, the waiting thread node is restored to a non-blocking state and the step of allocating the shared resources required for the first execution phase to the waiting thread in response to the shared resource allocation request is executed. If the reason for waking up the waiting thread node is a timeout, the waiting thread node is removed from the preset waiting list.
3. The method according to claim 2, characterized in that, The method further includes: Obtain the waiting time threshold for each waiting thread node in the preset waiting list; For any of the waiting thread nodes, when the waiting time of the waiting thread node in the preset waiting list exceeds the waiting time threshold, a wake-up event for the waiting thread node is generated.
4. The method according to claim 2, characterized in that, The method further includes: When the current shared resource semaphore increases, the preset waiting list is traversed to determine whether there is a waiting thread node in the preset waiting list that currently meets the execution conditions; If it is determined that any of the waiting thread nodes currently meets the execution conditions, a wake-up event for that waiting thread node is generated.
5. The method according to claim 2, characterized in that, The method further includes: When the current shared resource semaphore increases, it is determined whether the head waiting thread node in the preset waiting list currently meets the execution conditions; If it is determined that the head waiting thread node currently meets the execution conditions, a wake-up event for the head waiting thread node is generated; If it is determined that the current execution conditions of the head waiting thread node are not met, the wake-up event will not be generated.
6. The method according to claim 5, characterized in that, Adding the waiting thread node to the preset waiting list includes: The waiting thread node is added as a tail waiting thread node to the end of the preset waiting list so that the waiting thread nodes in the preset waiting list are awakened in the order they were added.
7. The method according to claim 1, characterized in that, The method further includes: When any thread completes all execution phases, it releases all shared resources acquired during the execution process. The current shared resource semaphore is updated to the sum of the thread's shared resource release amount and the current shared resource semaphore, so that the current shared resource semaphore increases.
8. A shared resource processing device, characterized in that, include: The acquisition module is used to acquire the shared resource allocation request and the current shared resource semaphore of the thread to be executed; wherein, the current shared resource semaphore represents the remaining amount of shared resource; The judgment module is used to determine whether the thread to be executed currently meets the execution conditions based on the relationship between the total demand for shared resources represented by the shared resource allocation request of the thread to be executed and the current shared resource semaphore. The allocation module is configured to, in response to the shared resource allocation request, allocate shared resources required for the first execution stage to the thread to be executed, provided that the thread to be executed currently meets the execution conditions; wherein the thread to be executed includes multiple execution stages; The update module is used to update the current shared resource semaphore to the difference between the total demand for shared resources and the current shared resource semaphore, so as to reserve the shared resources required by the thread to be executed for the remaining execution phase; The allocation module is further configured to, when determining that the thread to be executed does not currently meet the execution conditions, determine whether the thread to be executed is allowed to wait based on the thread configuration information represented by the shared resource allocation request of the thread to be executed; if it is determined that the thread to be executed is allowed to wait, designate the thread to be executed as a waiting thread, and the thread to be executed enters a blocked state; create a waiting thread node corresponding to the waiting thread based on the total shared resource demand of the waiting thread; add the waiting thread node to a preset waiting list to wait for a wake-up event outside the scope of a preset shared resource mutex lock; and analyze the wake-up reason of any waiting thread node in the preset waiting list when it receives the wake-up event.
9. An electronic device, characterized in that, include: At least one processor and memory; The memory stores computer-executed instructions; The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the method as described in any one of claims 1 to 7.