Shared resource processing method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computers, and discloses a shared resource processing method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining a shared resource distribution request of a to-be-executed thread and a current shared resource semaphore; judging whether the to-be-executed thread currently meets an execution condition or not according to a size relationship between a shared resource total demand quantity represented by a shared resource allocation request of the to-be-executed thread and a current shared resource semaphore; when it is determined that the to-be-executed thread currently meets the execution condition, in response to the shared resource allocation request, allocating shared resources required by the first execution stage to the to-be-executed thread; and updating the current shared resource semaphore to a difference value between the total demand quantity of the shared resources and the current shared resource semaphore. The current shared resource semaphore is reduced in advance according to the total demand quantity of the shared resources of the to-be-executed thread, the shared resources required by the to-be-executed thread are reserved, and the situation that the shared resources are in shortage in the running process of the to-be-executed thread is avoided.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a shared resource processing method, device, electronic device and storage medium. Background Art

[0002] In a server environment, when a client sends a service request to a server, the server usually creates a thread to process the service request. The thread obtains the shared resources of the server to respond to the service request. The shared resources include memory resources and the number of processor cores.

[0003] In the related art, a shared resource semaphore is usually set, and the semaphore count is set to the total number of shared resources. After a thread obtains a shared resource, the semaphore count is reduced by 1. After a thread releases a shared resource, the semaphore count is increased by 1. When the count is zero, the thread is stopped from initiating a shared resource request operation.

[0004] However, since a single complex thread requires different numbers of shared resources at different stages of the entire request response process, and the system limits the thread to only obtain part of the shared resources required for the current execution stage in order to ensure the utilization rate of shared resources, when the server has a large number of parallel threads, multiple complex threads may not be able to normally obtain the remaining shared resources during the execution process, causing a large number of threads to enter 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] The present application provides a shared resource processing method, device, electronic device and storage medium to solve the defects of related technologies such as causing a large number of threads to enter a blocked state at the same time, which is not conducive to ensuring the response efficiency of the server to user requests.

[0006] The first aspect of the present application provides a shared resource processing method, comprising:

[0007] Obtaining a shared resource allocation request and a current shared resource semaphore of a thread to be executed; wherein the current shared resource semaphore represents a current remaining amount of shared resources;

[0008] Determining whether the thread to be executed currently meets the execution condition according to 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;

[0009] In the case of determining that the thread to be executed currently meets the execution condition, in response to the shared resource allocation request, allocating the shared resources required for the first execution stage 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 demand and the current shared resource semaphore, so as to reserve the shared resources required for the remaining execution phase of the to-be-executed thread.

[0011] In an optional embodiment, the method further includes:

[0012] In the case where it is determined that the thread to be executed currently does not meet the execution condition, judging whether the thread to be executed is allowed to wait according to the thread configuration information represented by the shared resource allocation request of the thread to be executed;

[0013] When it is determined that the thread to be executed is allowed to wait, the thread to be executed is used as a waiting thread, and the thread to be executed enters a blocked state;

[0014] Creating a waiting thread node corresponding to the waiting thread according to the total demand for shared resources of the waiting thread;

[0015] Adding the waiting thread node to a preset waiting linked list to wait for a wake-up event outside a preset shared resource mutex lock range;

[0016] When any of the waiting thread nodes in the preset waiting linked list obtains the wake-up event, analyzing the wake-up reason of the waiting thread node;

[0017] If the reason for waking up the waiting thread node is that the execution condition is currently satisfied, the waiting thread node is restored to a waiting thread in a non-blocked state, and the step of responding to the shared resource allocation request and allocating the shared resources required for the first execution phase to the waiting thread is executed;

[0018] In the case where the wake-up reason of the waiting thread node is waiting timeout, the waiting thread node is removed from the preset waiting linked list.

[0019] In an optional embodiment, the method further includes:

[0020] Obtaining the waiting time threshold of each waiting thread node in the preset waiting linked list;

[0021] For any of the waiting thread nodes, when the waiting time of the waiting thread node in the preset waiting linked list exceeds the waiting time threshold, a wake-up event of the waiting thread node is generated.

[0022] In an optional embodiment, the method further includes:

[0023] When the current shared resource semaphore increases, the preset waiting linked list is traversed to determine whether there is a waiting thread node in the preset waiting linked list that currently meets the execution condition;

[0024] When it is determined that any of the waiting thread nodes currently meets the execution condition, a wake-up event for the waiting thread node is generated.

[0025] In an optional embodiment, the method further includes:

[0026] When the current shared resource semaphore increases, determining whether the head waiting thread node in the preset waiting linked list currently meets the execution condition;

[0027] In the case of determining that the head waiting thread node currently meets the execution condition, generating a wake-up event of the head waiting thread node;

[0028] In the case where it is determined that the head waiting thread node does not currently meet the execution condition, the wake-up event is not generated.

[0029] In an optional implementation, the adding the waiting thread node to a preset waiting linked list includes:

[0030] The waiting thread node is added as a tail waiting thread node to the tail of a preset waiting linked list, so that the waiting thread nodes in the preset waiting linked list are awakened in the order of addition.

[0031] In an optional embodiment, the method further includes:

[0032] When any thread completes all execution stages, it releases all shared resources acquired during the execution;

[0033] The current shared resource semaphore is updated to the accumulated value between the shared resource release amount of the thread and the current shared resource semaphore, so that the current shared resource semaphore increases.

[0034] A second aspect of the present application provides a shared resource processing device, including:

[0035] An acquisition module, used to acquire a shared resource allocation request of a thread to be executed and a current shared resource semaphore; wherein the current shared resource semaphore represents a current remaining amount of shared resources;

[0036] A judgment module, used to judge whether the thread to be executed currently meets the execution condition according to the relationship between the total demand of the shared resource represented by the shared resource allocation request of the thread to be executed and the current shared resource signal;

[0037] an allocation module, configured to allocate the shared resources required for the first execution phase to the thread to be executed in response to the shared resource allocation request when it is determined that the thread to be executed currently meets the execution condition; wherein the thread to be executed includes multiple execution phases;

[0038] The updating module is used to update the current shared resource semaphore to the difference between the total shared resource demand and the current shared resource semaphore, so as to reserve the shared resources required for the remaining execution phase of the to-be-executed thread.

[0039] A third aspect of the present application provides an electronic device, comprising: at least one processor and a memory;

[0040] The memory stores computer-executable instructions;

[0041] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor performs the method described in the first aspect and various possible designs of the first aspect.

[0042] A fourth aspect of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions. When a processor executes the computer-executable instructions, the method described in the first aspect and various possible designs of the first aspect are implemented.

[0043] A fifth aspect of the present application provides a computer program product, including computer instructions, which are used to enable a computer to execute the method described in the first aspect and various possible designs of the first aspect.

[0044] The technical solution of this application has the following advantages:

[0045] The present application provides a shared resource processing method, device, electronic device and storage medium, the method comprising: obtaining a shared resource allocation request and a current shared resource semaphore of a thread to be executed; wherein the current shared resource semaphore represents the current remaining amount of shared resources; judging whether the thread to be executed currently meets the execution condition according to the size relationship between the total shared resource demand represented by the shared resource allocation request of the thread to be executed and the current shared resource semaphore; in the case of determining that the thread to be executed currently meets the execution condition, responding to the shared resource allocation request, allocating the shared resources required for the first execution stage to the thread to be executed; wherein the thread to be executed includes multiple execution stages; updating the current shared resource semaphore to the difference between the total shared resource demand 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 reduces the current shared resource semaphore in advance according to the total shared resource demand of the thread to be executed, so as to reserve all the shared resources required by the thread to be executed, thereby avoiding the shortage of shared resources during the operation of the thread to be executed, and avoiding a large number of threads to be executed from entering a blocking state at the same time, thereby ensuring the response efficiency of the server to user requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the following is a brief introduction to the drawings required for use in the embodiments or the related technical descriptions. Obviously, the drawings described below are some embodiments of the present application, and a person skilled in the art can also obtain other drawings based on these drawings.

[0047] Figure 1 A schematic diagram of the structure of a shared resource processing system based on an embodiment of the present application;

[0048] Figure 2 A flowchart of a shared resource processing method provided in an embodiment of the present application;

[0049] Figure 3 A flowchart of an exemplary shared resource processing method provided in an embodiment of the present application;

[0050] Figure 4 A flowchart of another exemplary shared resource processing method provided in an embodiment of the present application;

[0051] Figure 5 A schematic diagram of the structure of a shared resource processing device provided in an embodiment of the present application;

[0052] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0053] The above drawings have shown clear embodiments of the present application, which will be described in more detail below. These drawings and text descriptions are not intended to limit the scope of the present disclosure in any way, but to illustrate the concepts of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0054] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0055] In addition, the terms "first", "second", etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. In the description of the following embodiments, the meaning of "multiple" is more than two, unless otherwise clearly and specifically defined.

[0056] In multithreaded programming, a semaphore is a counter used to control the access of multiple threads to shared resources. It can be used to synchronize threads. The usual usage is to set the semaphore count to the total number of sharable resources. After a thread acquires a semaphore, the count is reduced by 1. After a thread releases a semaphore, the count is increased by 1. When the count is zero, the operation of acquiring the semaphore will fail or be blocked. The semaphores provided by the operating system, whether Windows or Linux, are implemented in the above way.

[0057] But sometimes such semaphores do not meet the needs. Suppose there are 10 shared resources, thread A needs 5 resources, and thread B needs 8 resources. If they obtain resources one by one (waiting for signals), A may get 4 resources (4 waits succeeded) and B may get 6 resources (6 waits succeeded). When they continue to obtain (wait), they are blocked and cannot be awakened due to insufficient resources.

[0058] In view of the above problems, the embodiment of the present application provides a shared resource processing method, device, electronic device and storage medium, the method comprising: obtaining a shared resource allocation request and a current shared resource semaphore of a thread to be executed; wherein the current shared resource semaphore represents the current remaining amount of shared resources; judging whether the thread to be executed currently meets the execution condition according to the size relationship between the total shared resource demand represented by the shared resource allocation request of the thread to be executed and the current shared resource semaphore; in the case of determining that the thread to be executed currently meets the execution condition, responding to the shared resource allocation request, allocating the shared resources required for the first execution stage to the thread to be executed; wherein the thread to be executed includes multiple execution stages; updating the current shared resource semaphore to the difference between the total shared resource demand 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 reduces the current shared resource semaphore in advance according to the total shared resource demand of the thread to be executed, so as to reserve all the shared resources required by the thread to be executed, so as to avoid the shortage of shared resources in the thread to be executed during the operation, so as to avoid a large number of threads to be executed from entering a blocking state at the same time, thereby ensuring the response efficiency of the server to user requests.

[0059] The following specific embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. The embodiments of the present invention will be described below in conjunction with the accompanying drawings.

[0060] First, the structure of the shared resource processing system on which this application is based is described:

[0061] The shared resource processing method, device, electronic device and storage medium provided in the embodiments of the present application are suitable for allocating shared resources to threads to be executed including multiple asynchronous tasks. Figure 1 As shown, it is a structural diagram of the shared resource processing system based on the embodiment of the present application, which mainly includes a shared resource pool, a thread 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 the thread to be executed makes a shared resource allocation request, the shared resource allocation processing is performed on the thread to be executed according to the current shared resource semaphore.

[0062] The embodiment of the present application provides a shared resource processing method for allocating shared resources to threads to be executed including multiple asynchronous tasks. The execution subject of the embodiment of the present application is an electronic device, such as a server, a desktop computer, a laptop computer, a tablet computer, and other electronic devices that can be used to allocate shared resources.

[0063] like Figure 2 FIG. 1 is a flow chart of a shared resource processing method provided in an embodiment of the present application, the method comprising:

[0064] Step 201, obtaining a shared resource allocation request of a thread to be executed and a current shared resource semaphore.

[0065] The current shared resource semaphore represents the current remaining amount of shared resources. The initial value of the current shared resource semaphore, initialCount, is equal to the maximum count value of the semaphore, maximunCount, that is, equal to the total amount of shared resources in the shared resource pool.

[0066] Specifically, the shared resource allocation request issued by the thread to be executed can be obtained from the system, and at the same time, the current shared resource semaphore can be obtained, and this semaphore can intuitively reflect the remaining number of shared resources available for allocation in the current system.

[0067] Step 202 : judging whether the thread to be executed currently meets the execution condition according to the relationship between the total demand of the shared resource represented by the shared resource allocation request of the thread to be executed and the current shared resource semaphore.

[0068] Specifically, if the total demand for shared resources is less than or equal to the current shared resource semaphore, it is determined that the thread to be executed currently meets the execution condition; otherwise, it is determined that the thread to be executed currently does not meet the execution condition.

[0069] Step 203: when it is determined that the thread to be executed currently meets the execution condition, in response to the shared resource allocation request, allocate the shared resources required for the first execution phase 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, and different asynchronous tasks correspond to different execution stages. Taking the thread to be executed as processing a user data query request as an example, the asynchronous tasks are to parse the data query request data packet, perform a database query operation according to the request content, generate a response content according to the database query result, and return the response content to the client. The four asynchronous tasks correspond to the four execution stages, and the amount of shared resources required for different execution stages is different.

[0072] Step 204: Update the current shared resource semaphore to the difference between the total shared resource demand 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.

[0073] For example, taking the current shared resource semaphore as 10 and the total shared resource demand as 6, the updated current shared resource semaphore is equal to 4. Even if the shared resource amount required by the thread to be executed in the first execution stage is 1, that is, only 1 shared resource is currently allocated to the thread to be executed, since the shared resources required by the thread to be executed in the remaining execution stage are 5, in order to avoid the shared resources being allocated to other threads during its execution, resulting in the thread being unable to obtain the corresponding number of shared resources in the remaining execution stage, the current shared resource semaphore is reduced in advance to reserve the shared resources required for the remaining execution stage of the thread to be executed, ensuring that the thread that has started execution can complete all execution stages normally and will not enter a blocked state midway.

[0074] On the basis of the above embodiment, in order to further realize the reasonable allocation of shared resources, as an implementable manner, in one embodiment, the method further includes:

[0075] Step 301, when it is determined that the thread to be executed currently does not meet the execution condition, judging whether the thread to be executed is allowed to wait according to 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 used as a waiting thread, and the thread to be executed enters a blocked state;

[0077] Step 303, creating a waiting thread node corresponding to the waiting thread according to the total demand for shared resources of the waiting thread;

[0078] Step 304, adding the waiting thread node to a preset waiting linked list to wait for a wake-up event outside the preset shared resource mutex lock range;

[0079] Step 305, when any waiting thread node in the preset waiting list obtains a wake-up event, analyzing the wake-up reason of the waiting thread node;

[0080] Step 306, when the reason for waking up the waiting thread node is that the execution condition is currently satisfied, the waiting thread node is restored to a waiting thread in a non-blocking state, and the steps of responding to the shared resource allocation request and allocating the shared resources required for the first execution phase to the waiting thread are executed;

[0081] Step 307: When the reason for waking up the waiting thread node is waiting timeout, remove the waiting thread node from the preset waiting linked list.

[0082] The thread configuration information at least includes a waiting time threshold. If the waiting time threshold is 0, it is determined that the thread to be executed is not allowed to wait. If the waiting time threshold is greater than 0, it is determined that the thread to be executed is allowed to wait. Being outside the preset shared resource mutex lock range indicates that the thread to be executed releases the shared resource mutex lock, so that other threads to be executed can request to obtain the shared resource.

[0083] Specifically, in one embodiment, the waiting thread node may be added as a tail waiting thread node to the tail of a preset waiting linked list, so that the waiting thread nodes in the preset waiting linked list are awakened in the order in which they are added.

[0084] For example, Figure 3 As shown, a flowchart of an exemplary shared resource processing method provided by an embodiment of the present application is implemented by a wake-up event to suspend and wake up the waiting thread. When it is determined that the remaining available count value (the current shared resource semaphore) is less than the required number needSingle (the total demand for shared resources), it is determined that the thread to be executed does not currently meet the execution condition), and then it is determined whether the waiting time threshold is 0. To determine whether the thread to be executed is allowed to wait. That is, when the amount of resources required by the thread is greater than the current amount of available resources, the configuration information of the thread is further checked to determine whether the thread can wait. If the waiting time threshold is 0, that is, the thread is not allowed to wait, then failure is directly returned, that is, when it is determined that the thread is not allowed to wait, it does not block the operation, but directly ends the thread's attempt to obtain resources. If the waiting time threshold is not 0 (that is, the thread is allowed to wait), a WaitingThreadNode object (waiting thread node) is created and recorded as myself. The waiting thread node is a node for recording its waiting state and related information. After creating the WaitingThreadNode object, add myself to the end of the linked list, set the head and tail of the linked list, and then wait for the awakenedEvent signal (awakening event) outside the preset shared resource mutex range. When the thread is awakened, the thread node in the waiting linked list gets the awakening event, and makes subsequent judgments to further analyze the awakening reason of the waiting thread node. If the thread successfully obtains the signal after being awakened, that is, the awakening reason is that the execution condition is currently met, then it means that value is more than the required number needSingle, update value = value-needingle, and return success. If the thread does not successfully obtain the signal, it is determined that the awakening reason is waiting timeout, then delete myself from the waiting linked list, that is, remove the waiting thread node in the preset waiting linked list, and return failure.

[0085] Among them, Figure 3 The process shown can be implemented by the wait method, and the wait configuration parameters include 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, in order to prevent the thread from waiting indefinitely, when it is determined that the waiting time of a waiting thread node exceeds its waiting time threshold, a wake-up event of the waiting thread node is generated, and the wake-up event is used to notify the system to process the waiting thread. For example, when thread A waits for a timeout, a wake-up event of thread A is generated, so that the subsequent process can perform a timeout process on thread A. The timeout process includes operations such as removing thread A from the waiting list and recording a timeout log.

[0088] Specifically, in one embodiment, when it is determined that any waiting thread node has a waiting timeout, the resource requirements of the thread can be rechecked to determine whether the thread can continue to execute by adjusting the requirements (total shared resource requirements). For example, if a thread originally requires 10 memory blocks, but after the waiting timeout, it can be checked whether the number of required memory blocks can be reduced to continue to execute part of the task with the currently available fewer resources, such as reducing the memory usage by reducing the thread's data processing accuracy.

[0089] Furthermore, the thread waiting timeout event can also be recorded in the system log, including the thread ID, the type of resource being waited for, the timeout time and other information. This helps relevant technical personnel to conduct troubleshooting and performance analysis. For example, an event in which a network communication thread times out while waiting for network port resources can be recorded so that subsequent analysis can be conducted to determine whether the timeout is caused by a network configuration problem or by unreasonable resource requirements of the thread itself. When the thread waiting timeout event reaches a certain frequency or severity, a system alarm is triggered so that relevant technical personnel can take timely measures to prevent the system failure from further deteriorating.

[0090] Specifically, in one embodiment, when any thread completes all execution stages, all shared resources obtained during the execution process are released; the current shared resource semaphore is updated to the cumulative value between 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=Value+single is updated, indicating that the thread releases a specified amount (shared resource release amount) of shared resources. The shared resource release amount single of the thread may be equal to the total shared resource demand amount needSingle of the thread.

[0092] Specifically, in one embodiment, when the wake-up model is in high-efficiency 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 condition; when it is determined that any waiting thread node currently meets the execution condition, a wake-up event for the waiting thread node is generated.

[0093] Specifically, when the current shared resource semaphore increases, the preset waiting linked list is traversed from beginning to end, and when the traversal obtains a waiting thread node that currently meets the execution condition, the traversal is paused and a wake-up event of the 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 condition; when it is determined that the head waiting thread node currently meets the execution condition, a wake-up event for the head waiting thread node is generated; when it is determined that the head waiting thread node currently does not meet the execution condition, no wake-up event is generated.

[0095] For example, Figure 4 As shown, it is a flow chart of another exemplary shared resource processing method provided by an embodiment of the present application. First, when any single semaphore is released, the value of the semaphore is increased by single. Set the first node (head waiting thread node) in the preset waiting list as the current waiting thread, determine whether the head waiting thread node in the preset waiting list currently meets the execution condition, that is, determine whether the total shared resource demand needSingle of the head waiting thread node is less than or equal to the updated value. If so, determine that the head waiting thread node currently meets the execution condition, further update value=value-needSingle, remove the waiting thread in the preset waiting list, and generate a wake-up event to wake up the waiting thread. Further determine whether there are waiting thread nodes in the preset waiting list. If so, further use the next waiting thread node as the current waiting thread and repeat the above steps. If it is determined that the head waiting thread node does not currently meet the execution condition, further determine the wake-up mode (type). If the wake-up mode is a sequential mode, the process is directly terminated, that is, no wake-up event is generated. If the wake-up mode is the high-efficiency mode, it is further determined whether there are any waiting thread nodes in the preset waiting list. If so, the next waiting thread node is further used as the current waiting thread to traverse the preset waiting list from beginning to end until the waiting thread node that currently meets the execution condition or the tail node of the preset waiting list is obtained.

[0096] Among them, Figure 4The process shown can be implemented by the post method, and the post configuration parameter includes single.

[0097] The shared resource processing method provided by the embodiment of the present application obtains 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 current remaining amount of shared resources; according to the size relationship between the total shared resource demand represented by the shared resource allocation request of the thread to be executed and the current shared resource semaphore, it is judged whether the thread to be executed currently meets the execution condition; in the case of determining that the thread to be executed currently meets the execution condition, 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 demand and the current shared resource semaphore to reserve the shared resources required for the remaining execution stages of the thread to be executed. The method provided by the above scheme reduces the current shared resource semaphore in advance according to the total shared resource demand of the thread to be executed to reserve all the shared resources required by the thread to be executed, thereby avoiding the shortage of shared resources during the operation of the thread to be executed, and avoiding a large number of threads to be executed from entering a blocked state at the same time, thereby ensuring the response efficiency of the server to user requests. Through the mutual exclusion lock and event, multiple signal values ​​are obtained at one time, that is, the semaphore is implemented by the basic mutual exclusion lock and event, supports all operating systems, and has good cross-platform support capabilities. In addition, the acquisition and release of the semaphore in the embodiment of the present application adopts the function (wait and post) method similar to the system semaphore, with low learning cost, development and maintenance cost.

[0098] An embodiment of the present application provides a shared resource processing device, which is used to execute the shared resource processing method provided in the above embodiment.

[0099] like Figure 5 , which is a schematic diagram of the structure of a shared resource processing device provided in an embodiment of the present application. The shared resource processing device 50 comprises: an acquisition module 501 , a determination module 502 , an allocation module 503 and an update module 504 .

[0100] Among them, the acquisition module is used to 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 current remaining amount of shared resources; the judgment module is used to judge whether the thread to be executed currently meets the execution conditions according to the size relationship between the total shared resource demand represented by the shared resource allocation request of the thread to be executed and the current shared resource semaphore; the allocation module is used to respond to the shared resource allocation request and allocate the shared resources required for the first execution stage to the thread to be executed when it is determined 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 shared resource demand 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.

[0101] Regarding the shared resource processing device in this embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0102] The shared resource processing device provided in the embodiment of the present application 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 repeated here.

[0103] An embodiment of the present application provides an electronic device for executing the shared resource processing method provided in the above embodiment.

[0104] like Figure 6 FIG. 6 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present 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, so that the at least one processor executes the shared resource processing method provided in the above embodiment.

[0106] The electronic device provided in the embodiment of the present application 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 repeated here.

[0107] An embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, a shared resource processing method provided in any of the above embodiments is implemented.

[0108] The storage medium containing computer executable instructions provided in the embodiments of the present application can be used to store computer executable instructions of the shared resource processing method provided in the aforementioned embodiments. The implementation method and principle are the same and will not be repeated here.

[0109] An embodiment of the present application provides a computer program product, including computer instructions, which are used to enable a computer to execute the shared resource processing method provided in the above-mentioned embodiment.

[0110] The embodiments of the present application provide a computer program product that can be used to execute computer instructions of the shared resource processing method provided in the aforementioned embodiments. The implementation method and principle are the same and will not be repeated here.

[0111] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0112] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0113] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0114] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform some steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0115] A part of the present application may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of computer program instructions in computer-readable media includes, but is not limited to, source files, executable files, installation package files, etc., and accordingly, the way in which computer program instructions are executed by a computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to the computer.

[0116] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example for illustration. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device is 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 refer to the corresponding process in the aforementioned method embodiment, 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 the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A shared resource processing method, characterized in that: include: Obtaining a shared resource allocation request and a current shared resource semaphore of a thread to be executed; wherein the current shared resource semaphore represents a current remaining amount of shared resources; Determining whether the thread to be executed currently meets the execution condition according to 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; In the case of determining that the thread to be executed currently meets the execution condition, in response to the shared resource allocation request, allocating the shared resources required for the first execution stage 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 demand and the current shared resource semaphore, so as to reserve the shared resources required for the remaining execution phase of the to-be-executed thread.

2. The method according to claim 1, characterized in that The method further comprises: In the case where it is determined that the thread to be executed currently does not meet the execution condition, judging whether the thread to be executed is allowed to wait according to the thread configuration information represented by the shared resource allocation request of the thread to be executed; When it is determined that the thread to be executed is allowed to wait, the thread to be executed is used as a waiting thread, and the thread to be executed enters a blocked state; Creating a waiting thread node corresponding to the waiting thread according to the total demand for shared resources of the waiting thread; Adding the waiting thread node to a preset waiting linked list to wait for a wake-up event outside a preset shared resource mutex lock range; When any of the waiting thread nodes in the preset waiting linked list obtains the wake-up event, analyzing the wake-up reason of the waiting thread node; If the reason for waking up the waiting thread node is that the execution condition is currently satisfied, the waiting thread node is restored to a waiting thread in a non-blocked state, and the step of responding to the shared resource allocation request and allocating the shared resources required for the first execution phase to the waiting thread is performed; In the case where the wake-up reason of the waiting thread node is waiting timeout, the waiting thread node is removed from the preset waiting linked list.

3. The method according to claim 2, characterized in that The method further comprises: Obtaining the waiting time threshold of each waiting thread node in the preset waiting linked list; For any of the waiting thread nodes, when the waiting time of the waiting thread node in the preset waiting linked list exceeds the waiting time threshold, a wake-up event of the waiting thread node is generated.

4. The method according to claim 2, characterized in that: The method further comprises: When the current shared resource semaphore increases, the preset waiting linked list is traversed to determine whether there is a waiting thread node in the preset waiting linked list that currently meets the execution condition; When it is determined that any of the waiting thread nodes currently meets the execution condition, a wake-up event for the waiting thread node is generated.

5. The method according to claim 2, characterized in that: The method further comprises: When the current shared resource semaphore increases, determining whether the head waiting thread node in the preset waiting linked list currently meets the execution condition; In the case of determining that the head waiting thread node currently meets the execution condition, generating a wake-up event of the head waiting thread node; In the case where it is determined that the head waiting thread node does not currently meet the execution condition, the wake-up event is not generated.

6. The method according to claim 5, characterized in that The step of adding the waiting thread node to a preset waiting linked list includes: The waiting thread node is added as a tail waiting thread node to the tail of a preset waiting linked list, so that the waiting thread nodes in the preset waiting linked list are awakened in the order of addition.

7. The method according to claim 1, characterized in that The method further comprises: When any thread completes all execution stages, it releases all shared resources acquired during the execution; The current shared resource semaphore is updated to the accumulated value between the shared resource release amount of the thread and the current shared resource semaphore, so that the current shared resource semaphore increases.

8. A shared resource processing device, characterized in that: include: An acquisition module, used to acquire a shared resource allocation request of a thread to be executed and a current shared resource semaphore; wherein the current shared resource semaphore represents a current remaining amount of shared resources; A judgment module, configured to judge whether the thread to be executed currently meets the execution condition according to 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; an allocation module, configured to allocate the shared resources required for the first execution phase to the thread to be executed in response to the shared resource allocation request when it is determined that the thread to be executed currently meets the execution condition; wherein the thread to be executed includes multiple execution phases; The updating module is used to update the current shared resource semaphore to the difference between the total shared resource demand and the current shared resource semaphore, so as to reserve the shared resources required for the remaining execution phase of the to-be-executed thread.

9. An electronic device, characterized in that: include: at least one processor and memory; The memory stores computer-executable instructions; The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor performs the method according to 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, and when a processor executes the computer-executable instructions, the method according to any one of claims 1 to 7 is implemented.

Images