Shared resource allocation method, system, storage medium and chip based on SOC

Abstract

The present application discloses a shared resource allocation method, system, storage medium and chip based on SOC, belonging to the field of chip technology. The first process in the first domain applies to the first driver for the use of shared resources; the first driver obtains the status of the shared resources from the register in the hardware semaphore; if the shared resource is in an unlocked state, the first driver allocates the shared resource to the first process, writes the domain identifier of the first domain and the lock status of the shared resource that has been locked by the corresponding resource lock to the register; the first driver generates the lock information of the shared resource, and sends the lock information to the second process through the second driver in the second domain; the second process determines that the shared resource has been locked by the resource lock according to the lock information. The present application can maximize the use of resources through real-time resource allocation, save resources by shortening the communication link of resource allocation, realize multi-domain sharing of shared resources through mutual exclusion locks, and realize synchronization through the inter-domain synchronization mechanism of hardware semaphores.

Description

Technical Field

[0001] The present application relates to the field of chip technology, and in particular to a SOC-based shared resource allocation method, system, storage medium and chip. Background Art

[0002] Different operating systems can be installed in different domains of the System on Chip (SOC), such as Linux and Android. There will be competition for shared resources between the Linux and Android systems, and a synchronization mechanism is needed to ensure the accuracy of resource allocation. Among them, resources include built-in resources and external resources. Built-in resources include Inter-Integrated Circuit (I2C), Inter-IC Sound (I2S), Universal Asynchronous Receiver / Transmitter (UART), etc.; external resources include Double Data Rate (DDR) memory, Embedded Multi-Media Card (EMMC), etc.

[0003] like Figure 1 As shown in the figure, resources are allocated in advance to process 1 in Domain 1 and process 2 in Domain 2. Then process 1 can only access the built-in resources and external resources allocated to Domain 1, and process 2 can only access the built-in resources and external resources allocated to Domain 2. However, this allocation method cannot maximize the utilization of resources and is not convenient for resource switching.

[0004] like Figure 2 As shown in the figure, a resource management domain is set up to manage resources and then share resources with other domains. Process 1 in Domain1 and process 2 in Domain2 apply for resources from the resource management domain as clients, and the resource management domain allocates built-in resources and external resources to process 1 and process 2. However, this allocation method wastes the resources of the resource management domain to forward resource data, and the resource management domain and other domains interact through inter-domain communication, which lengthens the communication link. Summary of the invention

[0005] The present application provides a SOC-based shared resource allocation method, system, storage medium and chip, which are used to solve the problem that resources cannot be maximized when resources are allocated to domains in advance, the communication link is long when resources are allocated through resource management domains, and the resources of resource management domains are wasted. The technical solution is as follows:

[0006] According to a first aspect of the present application, a shared resource allocation method based on a SOC is provided, wherein the SOC includes at least two domains, a hardware semaphore and a shared resource, each domain includes a driver and at least one process, and the hardware semaphore includes at least one register, and the method includes:

[0007] A first process in the first domain applies to the first driver for using the shared resource;

[0008] The first driver obtains the state of the shared resource from the register in the hardware semaphore;

[0009] If the shared resource is in an unlocked state, the first driver allocates the shared resource to the first process, and writes the domain identifier of the first domain and the lock state of the shared resource being locked by the corresponding resource lock into the register;

[0010] The first driver generates locking information of the shared resource, and sends the locking information to the second process through the second driver in the second domain;

[0011] The second process determines, according to the locking information, that the shared resource has been locked by the resource lock.

[0012] In a possible implementation, the method further includes:

[0013] The first process applies to the first driver for releasing the shared resource;

[0014] The first driver writes an unlocking status indicating that the shared resource has been unlocked into the register;

[0015] The first driver generates unlocking information of the shared resource, and sends the unlocking information to the second process through the second driver in the second domain;

[0016] The second process determines, according to the unlocking information, that the shared resource has been unlocked.

[0017] In a possible implementation, the method further includes:

[0018] After the shared resource is locked by the first process, the first process writes shared data to the shared resource;

[0019] After the shared resource is unlocked by the first process, the second process locks the shared resource through the second driver and reads the shared data from the shared resource;

[0020] The second process releases the shared resource through the second driver.

[0021] In a possible implementation, when at least two second processes need to read the shared data, the second processes lock the shared resource through the second driver, including:

[0022] The second process applies to the second driver for using the shared resource;

[0023] The second driver obtains the state of the shared resource from the register;

[0024] If the shared resource is in an unlocked state, the second driver allocates the shared resource to the second process, and writes the domain identifier of the second domain and the lock state of the shared resource being locked by the corresponding resource lock into the register;

[0025] If the shared resource is in a locked state by another second process, the second driver generates task information according to the second process and adds the task information to a task list corresponding to the shared resource; after the shared resource is unlocked by the other second process, the second driver reads the task information from the task list, allocates the shared resource to the second process, and writes the domain identifier of the second domain and the locking state of the shared resource that has been locked by the corresponding resource lock into the register.

[0026] In a possible implementation, the method further includes:

[0027] After receiving the unlock information, the second driver obtains the sorting information from the register, the sorting information including the domain identifier of the target domain, the target domain being a domain selected from multiple domains currently applying to use the shared resource based on a rotation mechanism and a domain that has used the shared resource;

[0028] If the domain identifier of the target domain is the same as the domain identifier of the second driver, the second driver allocates the shared resource to the second process, and writes the domain identifier of the second domain and the lock status of the shared resource that has been locked by the corresponding resource lock into the register;

[0029] If the domain identifier of the target domain is different from the domain identifier of the second driver, the second driver again executes the step of obtaining the sorting information from the register after receiving the unlocking information.

[0030] In a possible implementation, the method further includes:

[0031] The first process writes the shared data into the register in the hardware semaphore, and sends the domain identifier of the first domain to at least one second process;

[0032] Each second process determines a corresponding register according to the domain identifier of the first domain, and reads the shared data from the register.

[0033] In a possible implementation manner, the SOC further includes a management domain, and the method further includes:

[0034] The management domain obtains the locking time length of the shared resource by the first domain;

[0035] If the locking time exceeds a predetermined time, the management domain notifies the first domain to release the shared resource;

[0036] If the notification fails, the management domain writes an unlocking status indicating that the shared resource has been unlocked into the register.

[0037] According to a second aspect of the present application, a shared resource allocation system based on a SOC is provided, wherein the SOC comprises at least two domains, a hardware semaphore and a shared resource, each domain comprises a driver and at least one process, and the hardware semaphore comprises at least one register;

[0038] A first process in the first domain is used to apply to the first driver for using the shared resource;

[0039] The first driver is used to obtain the state of the shared resource from the register in the hardware semaphore;

[0040] If the shared resource is in an unlocked state, the first driver is further configured to allocate the shared resource to the first process, and write into the register the domain identifier of the first domain and a locking state that the shared resource has been locked by a corresponding resource lock;

[0041] The first driver is further used to generate locking information of the shared resource, and send the locking information to the second process through the second driver in the second domain;

[0042] The second process is used to determine, according to the locking information, that the shared resource has been locked by the resource lock.

[0043] According to a third aspect of the present application, a computer-readable storage medium is provided, wherein at least one instruction is stored in the storage medium, and the at least one instruction is loaded and executed by a processor to implement the SOC-based shared resource allocation method as described above.

[0044] According to a fourth aspect of the present application, a chip is provided, wherein the chip includes the above-mentioned SOC-based shared resource allocation system.

[0045] The beneficial effects of the technical solution provided by this application include at least:

[0046] When the first process in the first domain needs to use shared resources, it can apply to the first driver in the first domain for the use of shared resources. When the first driver determines that the shared resources are in an unlocked state, it allocates the shared resources to the first process. This can maximize the use of resources through real-time resource allocation and save resources by shortening the communication link for resource allocation.

[0047] When the shared resource that the first domain and the second domain compete for use is allocated to the first domain, the domain identifier of the first domain and the lock status of the shared resource that has been locked by the corresponding resource lock can be written into the register of the hardware semaphore, and the locking information can be notified to the second domain. In this way, multi-domain sharing of shared resources can be achieved through mutex locks, and synchronization can be achieved through the inter-domain synchronization mechanism of the hardware semaphore.

[0048] The first process can share data with the second process through the register in the hardware semaphore, that is, the first process writes the shared data into the register, and the second process reads the shared data from the register, thereby realizing inter-domain communication. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0050] Figure 1 It is a schematic diagram of pre-allocating shared resources;

[0051] Figure 2 It is a schematic diagram of allocating shared resources through resource management domains;

[0052] Figure 3 is a schematic diagram of the structure of a SOC provided by an embodiment of the present application;

[0053] Figure 4 is a structural diagram of a SOC provided by another embodiment of the present application;

[0054] Figure 5 is a flow chart of a shared resource allocation method based on SOC provided by an embodiment of the present application;

[0055] Figure 6 is a flow chart of a shared resource allocation method based on SOC provided by an embodiment of the present application;

[0056] Figure 7 is a flow chart of a shared resource allocation method based on SOC provided by an embodiment of the present application;

[0057] Figure 8 It is a flowchart of a SOC-based shared resource allocation method provided by an embodiment of the present application. DETAILED DESCRIPTION

[0058] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.

[0059] SOC contains at least two domains, hardware semaphore (HS) and shared resources. Figure 3 In the example, two domains are used, namely, the first domain (Domain1) 310 and the second domain (Domain2) 320. The hardware semaphore includes at least one register ( Figure 3 (not shown in the figure), the shared resources include the built-in resources and external resources of the SOC, and each domain accesses the shared resources through the HS synchronization mechanism.

[0060] Each domain contains a driver ( / Dev / hssync) and at least one process. The number of processes is not limited in this application. Figure 4 In the example, the process in the first domain 410 is referred to as a first process 411 , and the process in the second domain 420 is referred to as a second process 421 ; the driver in the first domain 410 is referred to as a first driver 412 ; and the driver in the second domain 420 is referred to as a second driver 422 .

[0061] When multiple processes are created in a domain, the process names in Domain1 are recorded as D1_Process1, D1_Process2, and so on; the process names in Domain1 are recorded as D2_Process1, D2_Process2, and so on, to distinguish them.

[0062] like Figure 5 As shown, it shows a method flow chart of a shared resource allocation method based on SOC provided by an embodiment of the present application. The shared resource allocation method based on SOC can be applied to Figure 3 or Figure 4 The SOC-based shared resource allocation method may include:

[0063] Step 501: A first process in a first domain applies to a first driver for use of a shared resource.

[0064] The first process sends a request including a resource identifier to the first driver, where the resource identifier is used to indicate a shared resource that the first process is applying to use.

[0065] Optionally, the first process may also send a domain identifier of the first domain to the first driver.

[0066] Step 502: The first driver obtains the state of the shared resource from the register in the hardware semaphore.

[0067] A hardware semaphore includes multiple registers, and the addresses of the multiple registers can be mapped to various domains so that each domain can access each register according to the mapped address.

[0068] The states of shared resources include locked state and unlocked state. The locked state indicates that the shared resource is being used by a certain domain and cannot be allocated to other domains; the unlocked state indicates that the shared resource is not being used and can be allocated to any domain.

[0069] Step 503: If the shared resource is in an unlocked state, the first driver allocates the shared resource to the first process, and writes the domain identifier of the first domain and the lock state that the shared resource has been locked by the corresponding resource lock into the register.

[0070] The first driver may allocate the shared resource to the first process, create a resource lock corresponding to the shared resource, and use the resource lock to lock the shared resource. Specifically, the first driver may write the domain identifier of the first domain and the lock state of the shared resource locked by the resource lock into the register.

[0071] In this embodiment, the binding relationship between the shared resources and the resource lock can be pre-configured, and the first driver can determine the resource lock that needs to be created based on the shared resources and the binding relationship; or, the first driver can generate a binding relationship between the shared resources and the resource lock after creating the resource lock, so that other domains can uniquely determine the locked shared resources through the resource lock.

[0072] After the shared resource is locked, the first process can use the shared resource. For example, when the shared resource is a memory, the first process can write data into the memory; when the shared resource is a bus, the first process can use the bus for data transmission.

[0073] Step 504: The first driver generates locking information of the shared resource, and sends the locking information to the second process through the second driver in the second domain.

[0074] In this embodiment, domains other than the first domain are referred to as second domains, and each second domain includes a second driver and at least one second process.

[0075] The first driver can generate locking information including the domain identifier of the first domain and the resource lock, and determine the second driver in the second domain that needs to be notified; if one second driver needs to be notified, the locking information is sent point-to-point to the second driver through an interrupt; if at least two second drivers need to be notified, the locking information is broadcast to each second driver through an interrupt. Each second driver forwards the received locking information to the corresponding second process.

[0076] Step 505: The second process determines, based on the locking information, that the shared resource has been locked by the resource lock.

[0077] Each second process determines the locked shared resource according to the resource lock in the locking information, and determines that the shared resource is used by the first domain according to the domain identifier. When the shared resource is locked by the first domain, the second process will not apply to use the shared resource.

[0078] To summarize, the SOC-based shared resource allocation method provided in the embodiment of the present application can apply to the first driver in the first domain for the use of shared resources when the first process in the first domain needs to use shared resources. When the first driver determines that the shared resources are in an unlocked state, the shared resources are allocated to the first process. This can maximize resource utilization through real-time resource allocation and save resources by shortening the communication link for resource allocation.

[0079] When the shared resource that the first domain and the second domain compete for use is allocated to the first domain, the domain identifier of the first domain and the lock status of the shared resource that has been locked by the corresponding resource lock can be written into the register of the hardware semaphore, and the locking information can be notified to the second domain. In this way, multi-domain sharing of shared resources can be achieved through mutex locks, and synchronization can be achieved through the inter-domain synchronization mechanism of the hardware semaphore.

[0080] like Figure 6 As shown, it shows a flow chart of a shared resource allocation method based on SOC provided by an embodiment of the present application. The shared resource allocation method based on SOC can be applied to Figure 3 or Figure 4 The SOC-based shared resource allocation method may include:

[0081] Step 601: A first process in a first domain applies to a first driver for use of a shared resource.

[0082] Step 602: The first driver obtains the state of the shared resource from the register in the hardware semaphore.

[0083] Step 603: If the shared resource is in an unlocked state, the first driver allocates the shared resource to the first process, and writes the domain identifier of the first domain and the lock state that the shared resource has been locked by the corresponding resource lock into the register.

[0084] Step 604: The first driver generates locking information of the shared resource, and sends the locking information to the second process through the second driver in the second domain.

[0085] Step 605: The second process determines, based on the locking information, that the shared resource has been locked by the resource lock.

[0086] The process of steps 601-605 is the same as the process of steps 501-505, please refer to the description above for details, and will not be repeated here.

[0087] Step 606: The first process requests the first driver to release the shared resource.

[0088] After the first process has used up the shared resource, it needs to apply to the first driver to release the shared resource. Specifically, the first process sends an application including a resource identifier to the first driver, where the resource identifier is used to indicate the shared resource that the first process applies to release.

[0089] Optionally, the first process may also send a domain identifier of the first domain to the first driver.

[0090] Step 607: The first driver writes an unlocking status indicating that the shared resource has been unlocked into the register.

[0091] Step 608: The first driver generates unlocking information for the shared resource, and sends the unlocking information to the second process through the second driver in the second domain.

[0092] The first driver can generate unlocking information including the domain identifier of the first domain and the resource lock, and determine the second driver in the second domain that needs to be notified; if one second driver needs to be notified, the unlocking information is sent point-to-point to the second driver through an interrupt; if at least two second drivers need to be notified, the unlocking information is broadcast to each second driver through an interrupt. Each second driver forwards the received unlocking information to the corresponding second process.

[0093] Step 609: The second process determines that the shared resource has been unlocked according to the unlocking information.

[0094] Each second process determines the unlocked shared resource according to the resource lock in the unlock information, and determines that the shared resource is unlocked by the first domain according to the domain identifier. After the shared resource is unlocked by the first domain, the second process can apply to use the shared resource.

[0095] To summarize, the SOC-based shared resource allocation method provided in the embodiment of the present application can apply to the first driver in the first domain for the use of shared resources when the first process in the first domain needs to use shared resources. When the first driver determines that the shared resources are in an unlocked state, the shared resources are allocated to the first process. This can maximize resource utilization through real-time resource allocation and save resources by shortening the communication link for resource allocation.

[0096] When the shared resource that the first domain and the second domain compete for use is allocated to the first domain, the domain identifier of the first domain and the lock status of the shared resource that has been locked by the corresponding resource lock can be written into the register of the hardware semaphore, and the locking information can be notified to the second domain. In this way, multi-domain sharing of shared resources can be achieved through mutex locks, and synchronization can be achieved through the inter-domain synchronization mechanism of the hardware semaphore.

[0097] like Figure 7 As shown, it shows a flow chart of a shared resource allocation method based on SOC provided by an embodiment of the present application. The shared resource allocation method based on SOC can be applied to Figure 3 or Figure 4 The SOC-based shared resource allocation method may include:

[0098] Step 701: A first process in a first domain applies to a first driver for use of a shared resource.

[0099] Step 702: The first driver obtains the state of the shared resource from the register in the hardware semaphore.

[0100] Step 703: If the shared resource is in an unlocked state, the first driver allocates the shared resource to the first process, and writes the domain identifier of the first domain and the lock state that the shared resource has been locked by the corresponding resource lock into the register.

[0101] Step 704: After the shared resource is locked by the first process, the first process writes shared data to the shared resource.

[0102] When the shared resource is a memory, the first process and the second process can share data through the shared resource.

[0103] Specifically, the first process and the second process may pre-agree on an address in the shared resource for storing shared data, and after the shared resource is locked, the first process writes the shared data to be synchronized into the address.

[0104] Step 705: The first driver generates locking information of the shared resource, and sends the locking information to the second process through the second driver in the second domain.

[0105] Step 706: The second process determines, based on the locking information, that the shared resource has been locked by the resource lock.

[0106] Step 707: The first process requests the first driver to release the shared resource.

[0107] Step 708: The first driver writes an unlocking status indicating that the shared resource has been unlocked into the register.

[0108] Step 709: The first driver generates unlocking information of the shared resource, and sends the unlocking information to the second process through the second driver in the second domain.

[0109] Step 710: The second process determines that the shared resource has been unlocked according to the unlocking information.

[0110] The process of steps 701-703 and steps 705-710 is the same as the process of steps 601-609, please refer to the above description for details, and will not be repeated here.

[0111] Step 711: After the shared resource is unlocked by the first process, the second process locks the shared resource through the second driver and reads shared data from the shared resource.

[0112] When only one second process needs to read shared data, the second process applies to the second driver for using the shared resource, and the second driver obtains the state of the shared resource from the register. If the shared resource is in the unlocked state, the second driver allocates the shared resource to the second process, writes the domain identifier of the second domain and the lock state that the shared resource has been locked by the corresponding resource lock to the register. Then, the second process reads the shared data from the shared resource.

[0113] When at least two second processes need to read shared data, the second process locks the shared resource through the second driver, which may include: the second process applies to the second driver for the use of the shared resource; the second driver obtains the status of the shared resource from the register; if the shared resource is in an unlocked state, the second driver allocates the shared resource to the second process, and writes the domain identifier of the second domain and the locking status of the shared resource being locked by the corresponding resource lock to the register; if the shared resource is in a locked state locked by other second processes, the second driver generates task information according to the second process, and adds the task information to the task list corresponding to the shared resource; after the shared resource is unlocked by the other second processes, the second driver reads the task information from the task list, allocates the shared resource to the second process, and writes the domain identifier of the second domain and the locking status of the shared resource being locked by the corresponding resource lock to the register.

[0114] When at least two second processes need to read shared data, these second processes will compete for the use of shared resources. For a second process, if the shared resource is unlocked when the second process applies for the use of the shared resource, the shared resource can be directly allocated to the second process; if the shared resource is locked by other second processes when the second process applies for the use of the shared resource, the second process needs to wait in line and wait for the other second processes to release the shared resource before the shared resource is allocated to the second process.

[0115] Step 712: The second process releases the shared resource through the second driver.

[0116] Specifically, the second process applies to the second driver to release the shared resource, the second driver writes the unlocking state of the shared resource to the register, generates unlocking information of the shared resource, and sends the unlocking information to other second processes, and the other second processes determine that the shared resource has been unlocked according to the unlocking information.

[0117] In order to prevent a shared resource from being occupied by a domain for a long time (for example, a domain deadlock problem), the SOC also has a management domain with the highest authority, which can manage shared resources based on a timeout mechanism. Specifically, the management domain obtains the lock duration of the shared resource by the first domain; if the lock duration exceeds the predetermined duration, the management domain notifies the first domain to release the shared resource; if the notification fails, the management domain writes the unlocked state of the shared resource to the register. The lock duration can be set based on an empirical value.

[0118] The management domain may notify the first domain to release the shared resource through inter-domain communication. If the notification is successful, the first domain unlocks the shared resource; if the notification fails, the management domain unlocks the shared resource.

[0119] To summarize, the SOC-based shared resource allocation method provided in the embodiment of the present application can apply to the first driver in the first domain for the use of shared resources when the first process in the first domain needs to use shared resources. When the first driver determines that the shared resources are in an unlocked state, the shared resources are allocated to the first process. This can maximize resource utilization through real-time resource allocation and save resources by shortening the communication link for resource allocation.

[0120] When the shared resource that the first domain and the second domain compete for use is allocated to the first domain, the domain identifier of the first domain and the lock status of the shared resource that has been locked by the corresponding resource lock can be written into the register of the hardware semaphore, and the locking information can be notified to the second domain. In this way, multi-domain sharing of shared resources can be achieved through mutex locks, and synchronization can be achieved through the inter-domain synchronization mechanism of the hardware semaphore.

[0121] When multiple domains apply to use shared resources, in order to achieve fair competition between domains, we can adopt a rotation mechanism to evenly distribute the use of shared resources to each domain. Figure 8 As shown, taking the competition between the second domain and other domains for the use of shared resources as an example, the allocation process of the shared resources is as follows:

[0122] Step 801, after receiving the unlocking information, the second driver obtains the sorting information from the register, the sorting information including the domain identifier of the target domain, the target domain is a domain selected from multiple domains currently applying to use the shared resources based on the rotation mechanism and the domains that have used the shared resources.

[0123] Each time a shared resource is unlocked, we can update the sorting information in the register of the hardware semaphore according to the rotation mechanism, and the sorting information includes the next target domain that is ready to use the shared resource. Optionally, the sorting information can also include the domain currently using the shared resource.

[0124] Multiple domains can obtain the sorting information from the register and determine whether the next target domain to use the shared resources is itself based on the sorting information. If the target domain is itself, it will apply to use the shared resources; if the target domain is not itself, it will queue and wait.

[0125] The second driver may compare the domain identifier of the target domain with its own domain identifier. If the domain identifier of the target domain is the same as its own domain identifier, step 802 is executed; if the domain identifier of the target domain is different from its own domain identifier, step 803 is executed.

[0126] Step 802: If the domain identifier of the target domain is the same as its own domain identifier, the second driver allocates the shared resource to the second process, and writes the domain identifier of the second domain and the lock status of the shared resource that has been locked by the corresponding resource lock into the register.

[0127] The specific allocation process of the shared resources is detailed in step 503 and will not be repeated here.

[0128] Step 803: If the domain identifier of the target domain is different from the domain identifier of the second driver, the second driver again executes the step of obtaining the sorting information from the register after receiving the unlocking information.

[0129] After the second driver waits for the shared resource to be unlocked again, it obtains the updated sorting information from the register and determines whether the next target domain to use the shared resource is itself based on the sorting information. If the target domain is itself, it applies to use the shared resource; if the target domain is not itself, it queues and waits.

[0130] Different domains can use shared resources to synchronize a large amount of shared data, and can also use registers to synchronize a small amount of shared data, such as event notification.

[0131] Specifically, the first process writes the shared data into the register in the hardware semaphore and sends the domain identifier of the first domain to at least one second process; each second process determines the corresponding register according to the domain identifier of the first domain and reads the shared data from the register.

[0132] The first process and the second process can pre-agree on a register and an address in the register for storing shared data. The first process can write the shared data into the address and then send the domain identifier of the first domain to the second process through an interrupt. The second process determines the agreed register and the address in the register according to the domain identifier and reads the shared data from the address.

[0133] like Figure 4 As shown, it shows a structural block diagram of a shared resource allocation system based on SOC provided by an embodiment of the present application, the SOC includes at least two domains, hardware semaphores and shared resources, each domain includes a driver and at least one process, and the hardware semaphore includes at least one register;

[0134] The first process 411 in the first domain 410 is used to apply to the first driver 412 for using the shared resources;

[0135] A first driver 412 is used to obtain the state of the shared resource from the register in the hardware semaphore;

[0136] If the shared resource is in an unlocked state, the first driver 412 is further used to allocate the shared resource to the first process 411, and write the domain identifier of the first domain 410 and the lock state that the shared resource has been locked by the corresponding resource lock into the register;

[0137] The first driver 412 is further used to generate locking information of the shared resource, and send the locking information to the second process 421 through the second driver 422 in the second domain 420;

[0138] The second process 421 is used to determine whether the shared resource has been locked by the resource lock according to the locking information.

[0139] In an optional embodiment, the first process 411 is further used to apply to the first driver 412 for releasing the shared resource; write the unlocking state that the shared resource has been unlocked to the register; generate unlocking information of the shared resource, and send the unlocking information to the second process 421 through the second driver 422 in the second domain 420;

[0140] The second process 421 is further used to determine whether the shared resource has been unlocked according to the unlocking information.

[0141] In an optional embodiment, the first process 411 is further configured to write shared data to the shared resource after the shared resource is locked by the first process 411;

[0142] The second process 421 is further used to lock the shared resource through the second driver 422 and read the shared data from the shared resource after the shared resource is unlocked by the first process 411 ; and release the shared resource through the second driver 422 .

[0143] In an optional embodiment, when at least two second processes 421 need to read shared data, the second process 421 is further used to apply to the second driver 422 for using the shared resource;

[0144] The second driver 422 is also used to obtain the status of the shared resource from the register;

[0145] If the shared resource is in an unlocked state, the second driver 422 is further used to allocate the shared resource to the second process 421, and write the domain identifier of the second domain 420 and the lock state that the shared resource has been locked by the corresponding resource lock into the register;

[0146] If the shared resource is in a locked state by other second processes, the second driver 422 is also used to generate task information according to the second process 421 and add the task information to the task list corresponding to the shared resource; after the shared resource is unlocked by the other second process, the second driver 422 is also used to read the task information from the task list, allocate the shared resource to the second process 421, and write the domain identifier of the second domain 420 and the locking state of the shared resource that has been locked by the corresponding resource lock into the register.

[0147] In an optional embodiment, the second driver 422 is further configured to obtain the sorting information from the register after receiving the unlocking information, the sorting information including the domain identifier of the target domain, the target domain being a domain selected from multiple domains currently applying to use the shared resource based on the rotation mechanism and the domains that have used the shared resource;

[0148] If the domain identifier of the target domain is the same as the domain identifier of the own domain, the second driver 422 is further used to allocate the shared resource to the second process 421, and write the domain identifier of the second domain 420 and the lock status that the shared resource has been locked by the corresponding resource lock into the register;

[0149] If the domain identifier of the target domain is different from the domain identifier of the second domain, the second driver 422 is further configured to execute again the step of obtaining the sorting information from the register after receiving the unlocking information.

[0150] In an optional embodiment, the first process 411 is further used to write the shared data into a register in the hardware semaphore, and send a domain identifier of the first domain 410 to at least one second process 421;

[0151] Each second process 421 is further configured to determine a corresponding register according to the domain identifier of the first domain 410 and read shared data from the register.

[0152] In an optional embodiment, the management domain in the SOC is used to:

[0153] Obtaining the locking duration of the shared resource by the first domain 410;

[0154] If the locking time exceeds the predetermined time, the first domain 410 is notified to release the shared resource;

[0155] If the notification fails, the unlock status indicating that the shared resource has been unlocked is written to the register.

[0156] To summarize, the SOC-based shared resource allocation system provided in the embodiment of the present application can apply to the first driver in the first domain for the use of shared resources when the first process in the first domain needs to use shared resources. When the first driver determines that the shared resources are in an unlocked state, the shared resources are allocated to the first process. This can maximize resource utilization through real-time resource allocation and save resources by shortening the communication link for resource allocation.

[0157] When the shared resource that the first domain and the second domain compete for use is allocated to the first domain, the domain identifier of the first domain and the lock status of the shared resource that has been locked by the corresponding resource lock can be written into the register of the hardware semaphore, and the locking information can be notified to the second domain. In this way, multi-domain sharing of shared resources can be achieved through mutex locks, and synchronization can be achieved through the inter-domain synchronization mechanism of the hardware semaphore.

[0158] The first process can share data with the second process through the register in the hardware semaphore, that is, the first process writes the shared data into the register, and the second process reads the shared data from the register, thereby realizing inter-domain communication.

[0159] An embodiment of the present application provides a computer-readable storage medium, wherein the storage medium stores at least one instruction, and the at least one instruction is loaded and executed by a processor to implement the SOC-based shared resource allocation method as described above.

[0160] An embodiment of the present application provides a chip, wherein the chip includes any of the above-mentioned SOC-based shared resource allocation systems.

[0161] It should be noted that: the SOC-based shared resource allocation system provided in the above embodiment only uses the division of the above functional modules as an example when performing SOC-based shared resource allocation. In actual applications, the above functional allocation can be completed by different functional modules as needed, that is, the internal structure of the SOC-based shared resource allocation system is divided into different functional modules to complete all or part of the functions described above. In addition, the SOC-based shared resource allocation system provided in the above embodiment and the SOC-based shared resource allocation method embodiment belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0162] A person skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware or by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0163] The above description is not intended to limit the embodiments of the present application. Any adjustments, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the protection scope of the embodiments of the present application.

Claims

1. A shared resource allocation method based on SOC, characterized in that: The SOC includes at least two domains, a hardware semaphore and a shared resource, each domain includes a driver and at least one process, the hardware semaphore includes at least one register, and the method includes: A first process in the first domain applies to the first driver for using the shared resource; The first driver obtains the state of the shared resource from the register in the hardware semaphore; If the shared resource is in an unlocked state, the first driver allocates the shared resource to the first process, and writes the domain identifier of the first domain and the lock state of the shared resource being locked by the corresponding resource lock into the register; After the shared resource is locked by the first process, the first process writes shared data to the shared resource; The first driver generates locking information of the shared resource, and sends the locking information to the second process through the second driver in the second domain; The second process determines, according to the locking information, that the shared resource has been locked by the resource lock; The first process applies to the first driver for releasing the shared resource; The first driver writes an unlocking status indicating that the shared resource has been unlocked into the register; The first driver generates unlocking information of the shared resource, and sends the unlocking information to the second process through the second driver in the second domain; The second process determines, according to the unlocking information, that the shared resource has been unlocked; After the shared resource is unlocked by the first process, the second process locks the shared resource through the second driver and reads the shared data from the shared resource; The second process releases the shared resource through the second driver.

2. The SOC-based shared resource allocation method according to claim 1, characterized in that: When at least two second processes need to read the shared data, the second processes lock the shared resource through the second driver, including: The second process applies to the second driver for using the shared resource; The second driver obtains the state of the shared resource from the register; If the shared resource is in an unlocked state, the second driver allocates the shared resource to the second process, and writes the domain identifier of the second domain and the lock state of the shared resource being locked by the corresponding resource lock into the register; If the shared resource is in a locked state by another second process, the second driver generates task information according to the second process and adds the task information to a task list corresponding to the shared resource; after the shared resource is unlocked by the other second process, the second driver reads the task information from the task list, allocates the shared resource to the second process, and writes the domain identifier of the second domain and the locking state of the shared resource that has been locked by the corresponding resource lock into the register.

3. The SOC-based shared resource allocation method according to claim 1, characterized in that: The method further comprises: After receiving the unlock information, the second driver obtains the sorting information from the register, the sorting information including the domain identifier of the target domain, the target domain being a domain selected from multiple domains currently applying to use the shared resource based on a rotation mechanism and a domain that has used the shared resource; If the domain identifier of the target domain is the same as the domain identifier of the second driver, the second driver allocates the shared resource to the second process, and writes the domain identifier of the second domain and the lock status of the shared resource that has been locked by the corresponding resource lock into the register; If the domain identifier of the target domain is different from the domain identifier of the second driver, the second driver again executes the step of obtaining the sorting information from the register after receiving the unlocking information.

4. The SOC-based shared resource allocation method according to claim 1, characterized in that: The method further comprises: The first process writes the shared data into the register in the hardware semaphore, and sends the domain identifier of the first domain to at least one second process; Each second process determines a corresponding register according to the domain identifier of the first domain, and reads the shared data from the register.

5. The SOC-based shared resource allocation method according to any one of claims 1 to 4, characterized in that: The SOC further includes a management domain, and the method further includes: The management domain obtains the locking time length of the shared resource by the first domain; If the locking time exceeds a predetermined time, the management domain notifies the first domain to release the shared resource; If the notification fails, the management domain writes an unlocking status indicating that the shared resource has been unlocked into the register.

6. A shared resource allocation system based on SOC, characterized in that: The SOC includes at least two domains, a hardware semaphore and a shared resource, each domain includes a driver and at least one process, and the hardware semaphore includes at least one register; A first process in the first domain is used to apply to the first driver for using the shared resource; The first driver is used to obtain the state of the shared resource from the register in the hardware semaphore; If the shared resource is in an unlocked state, the first driver is further configured to allocate the shared resource to the first process, and write into the register the domain identifier of the first domain and a locking state that the shared resource has been locked by a corresponding resource lock; After the shared resource is locked by the first process, the first process is further used to write shared data to the shared resource; The first driver is further used to generate locking information of the shared resource, and send the locking information to the second process through the second driver in the second domain; The second process is used to determine, according to the locking information, that the shared resource has been locked by the resource lock; The first process is further used to apply to the first driver to release the shared resource; The first driver is further used to write an unlocking status indicating that the shared resource has been unlocked into the register; The first driver is further used to generate unlocking information of the shared resource, and send the unlocking information to the second process through the second driver in the second domain; The second process is further used to determine that the shared resource has been unlocked according to the unlocking information; After the shared resource is unlocked by the first process, the second process is further used to lock the shared resource through the second driver and read the shared data from the shared resource; The second process is further used to release the shared resource through the second driver.

7. A computer-readable storage medium, characterized in that: The storage medium stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the SOC-based shared resource allocation method according to any one of claims 1 to 5.

8. A chip, characterized in that: The chip includes: the SOC-based shared resource allocation system described in claim 6.

Images