CN112380025A

CN112380025A - Progress synchronization implementation method based on HSC

Info

Publication number: CN112380025A
Application number: CN202011391210.XA
Authority: CN
Inventors: 王志平
Original assignee: Individual
Current assignee: Individual
Priority date: 2020-12-03
Filing date: 2020-12-03
Publication date: 2021-02-19

Abstract

Logically, "synchronous" means time sequential, i.e., having a time or time of day characteristic. Functionally, "synchronization" is in fact divided into two steps, namely "blocking" and "triggering". In the prior processor technology, hardware cannot provide practical help for the requirements of most 'synchronous' applications required by software, so that 'synchronous' is virtually realized on the basis of software and only has synchronous control with logical synchronous effect. The invention realizes the process synchronous processing based on hardware control, thereby synchronously getting rid of the dependence and the encumbrance on an operating system, improving the efficiency of the whole system and leading the power consumption of the processor to be more reasonable.

Description

Progress synchronization implementation method based on HSC

Technical Field

The invention relates to the technical field of integrated circuits and computers, in particular to a process synchronization method based on a HSC (human traffic control system).

Background

"synchronization" is a real objective concept, i.e. the concept of associations between different individuals with respect to "time" or "moment" that necessarily exists in the objective world. In short, there are both possible but not fully defined sequential concepts and possible but not fully defined simultaneous concepts between different individuals. Under the existing computer system, all real objective concepts can be virtualized into software instructions executed according to a sequence. In other words, all synchronization concepts regarding "time" or "moment of time" can only be implemented logically, not physically really. In the application scenario with a small number of "synchronization" requirements, under the condition that the processor dominant frequency has a great advantage relative to the response speed required by the application, the synchronization requirement which is physically required can be obtained by the logically implemented synchronization concept under the existing background technology condition. But at the cost that all "synchronization" requirements can only be centered on the operating system running in the processor, which tends to greatly load the operating system and presents problems in data access security control.

In fact, in most applications, especially in multitasking and multi-user applications, the number of "synchronization" requirements can be very large. Software systems that are operating system-centric lose the synchronization effect of equating the logical "synchronization" effect to the "physical" requirement when the number of "synchronization" requirements reaches a certain level. If the number of "synchronization" requirements continues to increase, an operating system-centric software architecture will have a "stuck" effect on all processes that have "synchronization" requirements. As the number of "synchronization" requirements continues to increase, operating system-centric software systems may implement a denial of the "synchronization" requirements or crash the system.

Under the existing background technology, the actual implementer of "synchronization" is the "daemon" of the operating system, in other words, in the process of "synchronization", the operating system still needs to be in operation, and needs to complete complex operations on scheduling of processes and data query. This is not objectively achieved in the "synchronization" process, and in fact completely or nearly completely stops the processor from consuming power in the case where the application may be in a sleep state. Therefore, the method for realizing 'synchronization' under the existing background technology condition cannot provide a reasonable and high-efficiency power consumption control scheme.

Disclosure of Invention

HSC is an abbreviation of Hardware Synchronization Control, and obviously, the technical scheme of the invention realizes the Control of the Synchronization between the processes in the processor based on Hardware.

It is first determined that "synchronization" is a systematic concept. Therefore, in the technical solution of the present invention, "synchronization" does not belong to an independent concept of a process (including an operating system) in terms of software, and "synchronization" does not belong to an independent concept of a kernel in terms of hardware. In the technical solution of the present invention, a Hardware Synchronization Controller is implemented on a port of a "processor internal bus Controller" in a Hardware module manner, which is abbreviated as HSC (Hardware Synchronization Controller) hereinafter. The HSC receives an instruction from a Matrix module connected with the processor internal bus controller and other hardware modules, and completes related functions of blocking and triggering of synchronization.

The technical scheme of the invention uses but does not comprise a hardware implementation method related to process scheduling, and the implementation method realizes process scheduling and kernel load balancing in a multi-core system in a hardware mode, thereby enabling an operating system to obtain greater liberation. In the hardware implementation method for implementing process scheduling, a process is transmitted in each hardware module in the process of scheduling the process by specific hardware by using a bus process descriptor. "Bus Process descriptor" is abbreviated PDB and is an abbreviation for Process Descripter on Bus. The information carried by the PDB includes the state that the described process can be restored, as well as the code and data in the associated memory/cache of the described process. In the whole processor system, the PDB is transmitted to any kernel, the kernel can load the described process into the kernel through the PDB, and when the process is unloaded from the kernel, the kernel can also feed the process back to the 'processor internal bus controller' through the PDB for scheduling again. Therefore, after a process obtains the synchronized hardware resources of the HSC, if the process needs to enter the blocking state, it only needs to send the blocking related instruction to the HSC, and the process is recorded by the HSC and performs the operations of sleeping and waking up, without submitting any soft interrupt or other forms of process communication to the operating system. When another process needs to trigger a process in a certain blocking state, the trigger process only needs to send a trigger related instruction to the HSC, and does not need to submit any soft interrupt or other forms of process communication to the operating system, and the HSC can timely wake up the related process in a dormant state according to the trigger related instruction and make the awakened process quickly enter a processor internal bus controller for queue scheduling. Throughout the process of "synchronization" between processes, it is completely transparent to the operating system, i.e. the operating system is not affected by any "synchronization" operation (of course, the relevant processes under "synchronization" control are not affected by the load of the operating system, so that "synchronization" is delayed or rejected).

It is clear that HSC is also a hardware resource for processes. Like other hardware resources, HSCs are also devices mounted on "processor internal bus controller" ports, or special devices. Although in software use, the access to the HSC (sending HSC's associated instructions) does not require a hardware port number (or address) embodied on the "processor internal bus controller". However, in the hardware implementation, the HSC is still a port device connected to the "processor internal bus controller", that is, the HSC has a default port number (or address), and when the software executes the HSC-related instruction, the "processor internal bus controller" will default to the port where the HSC is located. Thus, from a software perspective, the HSC may in fact be considered as a part of a hardware module of the "processor internal bus controller". In the actual implementation of hardware, the technical solution of the present invention does not exclude that the HSC may be considered as a part of hardware modules in the "processor internal bus controller". In the actual implementation of hardware, the technical scheme of the invention does not exclude that the hardware realizes the HSC function but does not occupy the port number of the processor internal bus controller.

In the technical scheme of the invention, the HSC is used as a hardware resource, and the use authority of the HSC is managed according to different roles of processes in software and different working states of the HSC resource. Before clearly setting forth the role of the process in the software, the following definitions are first made (the names or abbreviations generated by the definitions only represent the symbols convenient for description of the definitions of the technical solution of the present invention, and do not represent the characteristic conditions defined by the technical solution of the present invention):

1. "Trigger host", abbreviated MHT, Master of HSC Trigger. The MHT has the highest usage right for the "HSC Resource" that has obtained the usage right (hereinafter, the single "HSC Resource" is simply referred to as HRU, an abbreviation of HSC Resource Unit). Before the MHT uses the HRU, the MHT first needs to send a HSC-related instruction to the HSC to request for obtaining the right of use of the HRU, and after obtaining the permission for use, the MHT can obtain the Resource identification number of the HRU (hereinafter, the Resource identification number of the HRU is simply referred to as the HRID, which is an abbreviation of HSC Resource ID) that is authorized to be used. In the management of the MHT on the HRU usage right, the MHT itself is used as a "trigger process" in the use of the HRU, that is, the MHT itself cannot become a process recorded in the HRU in a blocking state. A process that can use the HRU and become a "blocking process", i.e. a process that can enter a blocking state using the HRID (i.e. the process goes to sleep) and is logged PDB information by the HRU, must first be granted by the MHT, otherwise any HSC instruction that an unlicensed process tries to enter a blocking state using the HRID will be rejected. In addition, as a "trigger process" to the HRU, the MHT has a natural right to trigger, and at the same time the MHT can also authorize other processes to trigger the HRU. After the MHT authorizes a process to have the right to trigger the HRU, the authorized process can directly trigger the relevant "blocking process" recorded in the HRU through the HSC-related instruction. Of course, any process that does not obtain MHT authorization, HSC-related commands that trigger the relevant HRU, will be rejected by the HSC;

2. "operating System", abbreviated as OS, an abbreviation of Operation System. As an MHT has usage and administrative rights to the HRU, before it can get that right using the relevant HSC instructions, the relevant processes must first get permission from the OS to send the relevant HSC instructions to the HSC to become an MHT. The OS grants a process the right to become MHT by granting a key to the process. The OS is the only one that has to send the relevant command to the HSC, and set a Key for the HSC to authenticate whether a process qualifies as MHT, which is called "HSC Key" and abbreviated as "SKH", i.e. abbreviation of Security Key of HSC. Any process sending a relevant HSC command to the HSC for becoming MHT must carry the correct SKH in the parameters of the relevant HSC command sent, otherwise the command is rejected by the HSC;

3. "Trigger Process", abbreviated PHT, an abbreviation for Process of HSC Trigger, as described in the description for MHT;

4. "blocked Process", abbreviated as BPH, i.e. the abbreviation of Blocking Process of HSC, as described in the description for MHT.

In terms of hardware implementation, i.e. with respect to the HRU described above, the HSC controls a series of HRUs, each HRU containing the following necessary data information:

1. "MHT Process number", hereinafter abbreviated PIDM, an abbreviation of Process ID of MHT. The PIDM is the process number of the MHT, and when a HRU is allocated to the MHT by the HSC, it indicates that the HRU usage right is owned by the MHT, and the PIDM of the HRU is set as the process number of the MHT by the HSC. When any process sends an instruction to the HRU by the identity of the MHT, the HSC takes the process number of the process as the information of security authentication, and if the process number of the process is not equal to the PIDM, the relevant HSC instruction is rejected;

2. "Trigger Key", hereinafter abbreviated as SKT, an abbreviation of Security Key of Trigger. When the MHT authorizes the PHT to have the triggering right for the HRU governed by the MHT, the PHT is granted to trigger a secret key, and the secret key is the SKT. The relevant HSC command parameters used by the PHT trigger HRU need to provide the correct SKT, and its relevant HSC command is executed, otherwise it is rejected by the HSC (the MHT may use the process number as a security certificate for the HRU trigger);

3. "Blocking Key", hereinafter abbreviated as SKB, an abbreviation for Security Key of Blocking. When the MHT authorizes the BPH to have the blocking right for the HRU governed by the MHT, the blocking right is completed by granting the BPH to block a secret key, and the secret key is the SKB. SKB and SKT are independent of each other for an HRU, and there is no correlation, and in practical applications, SKB and SKT should be avoided to be the same. BPH wants to block using HRU, using the relevant HSC command parameters that require the correct SKB to be provided, and which are otherwise rejected by the HSC;

4. "blocked Process item", hereinafter abbreviated as BPE, an abbreviation for Blocking Process Entry. When a BPH successfully completes blocking in the HRU, the HSC creates a BPE for that BPH in the HRU, which may have 1 or more BPEs. Thus, multiple blocking processes can be supported for one HRU (theoretically without limiting the number of supported blocking processes). Each BPE contains two items of data content: "PDB information" and "Trigger Mask", where "Trigger Mask" is hereinafter abbreviated as TMB, an abbreviation of Trigger Mask of BPH. BPH needs to specify a default TMB in the command parameters when sending relevant HSC commands to HSCs. The MHT or PHT also needs to specify the TMB to be triggered in the instruction parameters when sending the relevant HSC instruction to the HSC, and the "needed triggering TMB" specified by the relevant HSC instruction triggering each operation is or-ed with the original TMB saved in the BPE. Only when the TMB of the BPE is all 1 after the last triggering, the corresponding BPH is really triggered, namely the HSC dispatches the PDB information of the BPE and enables the BPH to enter a processor internal bus controller for process scheduling, and the related HSC instruction of the triggering operation at the negative side only writes the result of the TMB bit OR operation back to the corresponding position in the BPE.

Roles MHT, OS, PHT, and BPH of the process in the software finish the specific application to the HSC by sending a HSC instruction to the HSC, and specifically include the following instructions:

1. "HSC Key" instruction having the word "HSCSKH" as the instruction symbol, but is not limited to "HSCSKH" only as the instruction symbol. Any process that has to be licensed by the OS to become MHT, having the right to obtain HRU usage and management, authorizes the process to become MHT by the OS by giving it a key (i.e., SKH) to the process that applies to use and manage the HRU. The MHT obtaining SKH must use the correct SKH as an authentication condition in the relevant HSC instruction for using and managing the HRU, and the relevant instruction can be executed by the HSC. The HSCSKH instruction is an instruction issued by the OS to the HSC, and is used to set SKH in the HSC for authentication of MHT by the HSC. Therefore, the HSCSKH instruction can only be issued by the OS and executed by the HSC, and includes the following necessary parameters:

parameter 1, "OS Process number," i.e., the process number of the OS. For convenience, the default OS is a process with a process number of 0, but the OS is not limited to be 0, and only means that the OS has a fixed default process number in the whole processor software and hardware environment. The "OS process number" parameter is used by the HSC as a security authentication condition for executing the HSCSKH instruction, i.e. the instruction is executed by the HSC only if the "OS process number" in the instruction parameter is equal to the default fixed OS process number of the system, otherwise, the instruction is rejected by the HSC;

parameter 2, "HSC key", i.e. the specific value of SKH in HSC. When the "OS process number" is correctly authenticated by the HSC, the value of the parameter "HSC key" is written into the HSC hardware register by the HSC, which is the specific value of SKH;

2. the "MHT set" instruction takes the character "HSCSETM" as an instruction symbol, but is not limited to only taking "HSCSETM" as an instruction symbol. The hscset m is an instruction that the MHT needs to send to the HSC to acquire the HRU. The HSC is a specific execution hardware module of the hscset instruction, and after executing the hscset instruction, the HSC uniquely associates the process number of the MHT with the HRU, that is, writes the process number of the MHT into the PIDM of the HRU, and at the same time, the HSC feeds back the HRID of the HRU allocated by the HSC to the MHT. The HSCSETM instruction contains the following necessary parameters:

parameter 1, "HSC Key", i.e., SKH. SKH is an authentication key for the hscset instruction to execute, and only if SKH is equal to SKH set by the instruction HSCSKH, the HSC will execute the hscset instruction, otherwise the HSC will refuse to execute;

parameter 2, "MHT process number", i.e. PIDM. If the parameter "HSC key" is authenticated, the HSC writes the parameter "MHT process number" into the PIDM of the HRU allocated to the MHT (i.e. make the PIDM of the HRU equal to the parameter "MHT process number");

3. the "trigger key" instruction uses the word "HSCSKT" as the instruction symbol, but is not limited to use "HSCSKT" as the instruction symbol. The HSCSKT authorizes the MHT to trigger the HRU right governed by the MHT for the PHT, and sends an instruction to the HSC to set an authentication key, namely set SKT. The HSC is a specific execution hardware module of the HSCSKT instruction, and after executing the HSCSKT instruction, the HSC modifies the SKT of the HRU to a value specified by the instruction parameter. When the PHT triggers the HRU using the HSC command, the HSC needs to provide the correct SKT in the HSC command parameter, and only if the SKT in the HSC command parameter is equal to the SKT of the HRU, the HSC will execute the HSC command sent by the PHT to trigger the HRU. The HSCSKT contains the following essential parameters:

parameter 1, "MHT process number," i.e., the process number of the MHT (i.e., the PIDM). The 'MHT process number' parameter is used by the HSC as a security authentication condition for executing the HSCSKT instruction, i.e. only if the 'MHT process number' in the instruction is equal to the PIDM of the HRU, the instruction will be executed by the HSC, otherwise, the instruction will be rejected by the HSC;

parameter 2, "resource identification number", i.e., HRID. The HRID specifies a resource identification number of a target HRU operated by the instruction, namely the HRID of the HRU;

parameter 3, "trigger Key", or SKT. Under the condition that the parameter "MHT process number" is authenticated, the HSC writes the parameter "trigger key" into the SKT of the HRU specified by the parameter HRID (i.e. make the SKT of the HRU equal to the parameter "trigger key");

4. the "block key" instruction uses the word "hscsbb" as the instruction symbol, but is not limited to use "hscsbb" as the instruction symbol. The HSCSKB authorizes the BPH to use the HRU governed by the MHT to enter a blocking state for the MHT, and sends an instruction to the HSC to set an authentication key, namely set SKB. The HSC is the specific execution hardware module of the HSCSKB instruction, which modifies the SKB of the HRU to the value specified by the instruction parameter after executing the HSCSKB instruction. When the BPH attempts to enter the blocking state using the HSC-related command, it is necessary to provide the correct SKB in the HSC-related command parameters, and only if the SKB in the command parameters is equal to the SKB of the HRU, will the HSC execute the HSC-related command sent by the BPH to enter the blocking state using the HRU. Hscssb contains the following essential parameters:

parameter 1, "MHT process number," i.e., the process number of the MHT (i.e., the PIDM). The MHT process number parameter is used by the HSC as a security authentication condition for executing the hscsbb instruction, i.e. the instruction is executed by the HSC only if the MHT process number in the instruction is equal to the PIDM of the HRU, otherwise, the instruction is rejected by the HSC;

parameter 3, "blocking Key", or SKB. If the parameter "MHT process number" is authenticated, the HSC writes the parameter "blocking key" into the SKB of the HRU specified by the parameter HRID (i.e. make the SKB of the HRU equal to the parameter "blocking key");

5. the "synchronous block" instruction uses the character "HSCBLK" as an instruction symbol, but is not limited to use "HSCBLK" as an instruction symbol. HSCBLK is an instruction for BPH to attempt to cause a process specified by an instruction parameter to enter a blocked state using the HRU specified by the instruction parameter. The HSC is a specific execution hardware module of the HSCBLK instruction, after the HSCBLK instruction is executed, the HSC establishes a BPE for the BPH, and records PDB information and initial TMB information carried by parameters of the HSCBLK instruction of the BPH into the BPE. HSCBLK contains the following necessary parameters:

parameter 1, "blocking key", i.e., SKB. The SKB is an authentication key for the HSC to execute the HSCBLK instruction, and the HSC executes the HSCBLK instruction only if the SKB is equal to the SKB set by the instruction HSCSKB, otherwise the HSC rejects execution;

parameter 2, "HRU resource number", HRID. The HRID specifies a resource identification number of a target HRU operated by the instruction, namely the HRID of the HRU;

parameter 3, "PDB information", i.e., PDB for BPH. Under the condition that the parameter blocking key passes the authentication, the HSC writes the parameter PDB information into the BPE newly created by the HSC for the BPH in the HRU specified by the HRID, so that the PDB information in the BPE is equal to the parameter PDB information;

parameter 4, "initial TMB", i.e., TMB initial value. Under the condition that the parameter "blocking key" passes the authentication, the HSC writes a parameter "initial TMB" into the BPE newly created by the HSC for BPH in the HRID-designated HRU, so that the TMB in the BPE is equal to the "initial TMB";

6. the MHT triggers an instruction, which takes the character "HSCMTRG" as an instruction symbol, but is not limited to taking "HSCMTRG" as an instruction symbol only. The HSCMTRG is issued by the MHT to the HSC for triggering the HRU specified by the instruction parameters. The HSC is a concrete execution hardware module of the HSCMTRG instruction, in the process of executing the HSCMTRG instruction, the HSC carries out bit OR operation according to the TMB specified by the instruction parameter and the TMBs of all the BPEs in the HRU specified by the instruction parameter, and judges whether the PDB recorded by the corresponding BPE is dispatched from the HRU or not by taking the operation result as judgment, and the PDB enters a 'bus controller inside a processor' to carry out process dispatching. If the operation structure is all 1, scheduling the corresponding PDB from the HRU and carrying out process scheduling. If the operation result is not all 1's, the operation result is written back to the TMB of the BPE. The HSCMTRG contains the following parameters:

parameter 1, "MHT process number," i.e., the process number of the MHT (i.e., the PIDM). The MHT process number parameter is used by the HSC as a security authentication condition for executing the HSCMTRG instruction, i.e. the instruction is executed by the HSC only if the MHT process number in the instruction is equal to the PIDM of the HRU, otherwise, the instruction is rejected by the HSC;

parameter 3, "trigger mask", i.e., TMB. The parameter is a trigger mask triggered by all BPEs in the target HRU;

7. the "PHT trigger" instruction uses the character "hscprg" as an instruction symbol, but is not limited to use "hscprg" as an instruction symbol. The HSCPTRG is issued by the PHT to the HSC to trigger the instruction for the HRU specified by the instruction parameters. The HSC is a concrete execution hardware module of the HSCPTRG instruction, and in the process of executing the HSCPTRG instruction, the HSC performs bit OR operation according to the TMB specified by the instruction parameter and the TMBs of all the BPEs in the HRU specified by the instruction parameter, and uses the operation result as a judgment result to judge whether the PDB recorded by the corresponding BPE is dispatched from the HRU or not, and makes the PDB enter a 'bus controller inside a processor' to perform process dispatching. If the operation structure is all 1, scheduling the corresponding PDB from the HRU and carrying out process scheduling. If the operation result is not all 1's, the operation result is written back to the TMB of the BPE. The HSCMTRG contains the following parameters:

parameter 1, "trigger Key", or SKT. The SKT is an authentication key of the HSC for executing the hscstrg instruction, and the HSC executes the hscstrg instruction only when the SKT is equal to the SKT set by the instruction HSCSKT, otherwise, the HSC rejects execution;

8. the "OS trigger" instruction is signed by the character "HSCSTRG", but is not limited to being signed by "HSCSTRG". The HSCSTRG is an instruction sent to the HSC by the OS and used for triggering all HRUs unconditionally, the HSC is a specific execution hardware module of the HSCSTRG instruction, and PDBs in a blocking state and stored in all the HRUs can be dispatched from the HRUs unconditionally in the process of executing the HSCSTRG instruction, and are enabled to enter a processor internal bus controller for process dispatching. HSCSTRG contains the following parameters:

parameter 1, "OS Process number," i.e., the process number of the OS. The "OS process number" parameter is used by the HSC as a security authentication condition for executing the hsctrg instruction, i.e. the instruction will only be executed by the HSC if the "OS process number" in the instruction parameter is equal to the default fixed OS process number of the system, otherwise, the HSC will refuse to execute the instruction.

Drawings

Fig. 1 is a schematic block diagram of a possible hardware of the technical solution of the present invention, which is a schematic diagram of a basic solution and does not show that the technical solution of the present invention needs to be fixed to a structure shown in the figure. The figure illustrates a simple structure with 4 cores (core 0 to core 3, respectively) to illustrate the location of the hardware involved in the present invention in the processor and to illustrate the transmission of the instructions from the cores to the HSC hardware module. In the actual implementation of the processor hardware, there should be other modules not shown in the figures. As shown in the figure, the "processor internal bus controller" is not a specific module in hardware implementation, and the HSS, the HSC, and the Matrix in the range shown as the "processor core bus controller" are all within the range controlled by the "processor internal bus controller", that is, the above-mentioned module in the "processor internal bus controller" can establish the association of the relevant instruction transmission with any one of the 4 cores shown in the figure through the "processor internal bus controller";

fig. 1 shows that the HSC is a schematic Hardware implementation of the technical solution of the present invention, and the HSS is an abbreviation of hard Synchronization Stack, and is controlled by the HSC, and is used for storing a dedicated memory/cache of the HRU data. Matrix is a module that implements all modules with associations and physical connections between cores. In the process of implementing the technical scheme of the invention, a hardware line in a certain form is constructed, and a signal handshake protocol and a time sequence in a certain form are implemented on the hardware line, so as to implement instruction transmission between a kernel (any one of kernel 0 to kernel 3) and an HSC and PDB transmission and scheduling of a process. It is shown and emphasized that when a process in software executes a "sync" application, an instruction for HSC operation is issued in the kernel, communicated to the HSC by the illustrated hardware module, and fed back by the HSC to the HSC instruction issued by the process, and processed by the corresponding hardware, to complete the "sync" application required by the process.

Fig. 2 is a logic diagram illustrating PDB transmission or scheduling inside a processor according to the technical solution of the present invention. "peripheral 0" to "peripheral n" shown in fig. 2 represent external devices mounted directly or indirectly on the "processor internal bus controller" inside the processor;

FIG. 2 is a "HSC" diagram of the HSC of the present invention showing the PDB of a process being registered and scheduled when the process is blocked and triggered in a "synchronization" application;

"PuPQ", "PrPQ" shown in FIG. 2 represent "public scheduling queue" and "private scheduling queue" with respect to PDB scheduling of processes implemented in the Matrix shown in FIG. 1, or implemented in other modules connected and controlled by the "processor internal bus controller", respectively. As shown in the figure, the "private scheduling queue" performs scheduling of the PDB of the process for each core, and the "public scheduling queue" performs scheduling of the PDB of the process for the "private scheduling queue" of all cores, and performs balancing of the core load, as shown by a line F;

as shown in fig. 2, the process scheduled from any kernel may be "a new process", "a process temporarily scheduled out of a kernel but not blocked", "a process scheduled out of a kernel due to a blocking requirement". As shown by line A, a PDB for a process scheduled from any core is transmitted to PuPQ or HSC as shown by lines C and B, respectively. Wherein, the PDB transmitted to HSC indicates that the PDB related process dispatches out of the kernel due to the 'blocking requirement', that is, the process sends HSC related instruction to HSC in the kernel to make the process enter the blocking state;

as shown in fig. 2, the interrupt issued by the peripheral, as indicated by line E, does not refer to a specific process, but refers to a message interrupt or other type of interrupt issued by the peripheral to the OS, and these interrupts may also be packaged as PDBs and then given priority to entering the PuPQ for scheduling. In fact, both PuPQ and PrPQ are scheduling queues with a priority ordering function, as shown in the figure, the darker color indicates that the PDB has a higher priority, and the PDB with the higher priority is scheduled into the core more preferentially;

as shown in fig. 2, the trigger signal sent by the peripheral device, as indicated by the line G, is not specific to a process, but refers to a trigger signal sent by the peripheral device, and is used for triggering a driving process corresponding to the peripheral device in a sleep state (i.e., a blocking state). As with the trigger signals issued from processes in any kernel (as indicated by line H), they indicate that a peripheral or kernel process issued a relevant HSC instruction to the HSC for triggering a relevant process in the HSC in a blocked state. When the HSC executes the relevant trigger instructions, the PDB of the relevant process is scheduled out of the HSC and into PuPQ for process scheduling, as shown by line D.

Detailed Description

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following describes specific embodiments of the present invention with reference to the drawings. It is obvious that the drawings in the following description are only some examples of the invention, and that for a person skilled in the art, other drawings and embodiments can be obtained from them without inventive effort.

For the sake of simplicity, the drawings only schematically show the parts relevant to the present invention, and they do not represent the actual structure or flow of the product. Moreover, to facilitate understanding of the drawing figures, some of the figures may have identical structures or features, only one of which is schematically depicted or only one of which is labeled. In this document, "one" means not only "only one" but also a case of "more than one".

Example 1

One embodiment of the invention, which implements that the OS authorizes the MHT to use and manage the HRU in the HSC, comprises the following steps:

step 1, under the condition that the HSC is not set with SKH or the OS needs to change the SKH of the HSC, the OS sends an HSCSKH instruction to the HSC. If the HSC is set with SKH and the OS does not need to change the SKH of the HSC, directly executing the step 2;

step 2, the process applies for becoming MHT to the OS through a process communication channel or other interrupt modes;

step 3, the OS confirms that the authorization process can become MHT, and provides SKH for the process;

step 4, the MHT sends an HSCSETM instruction to the HSC by using the SKH granted by the OS;

and step 5, the HSC executes the HSCSETM instruction and feeds back the HRID of the HRU to the MHT.

Example 2

One embodiment of the invention realizes that MHT sets SKT for HRU governed by MHT, and comprises the following steps:

step 1, MHT generates a private key thereof;

step 2, the MHT uses the generated private key as an SKT and sends an HSCSKT instruction to the HSC;

and step 3, the HSC executes the HSCSKT instruction, and modifies the SKT of the HRU pointed by the instruction parameter HRID into the SKT in the instruction parameter.

Example 3

One embodiment of the invention realizes that MHT sets SKB for HRU governed by MHT, and comprises the following steps:

step 1, MHT generates a private key thereof;

step 2, the MHT uses the generated private key as an SKB and sends an HSCSKB instruction to the HSC;

step 3, the HSC executes the HSCSKB instruction, and modifies the SKB of the HRU indicated by the instruction parameter HRID into the SKB in the instruction eucalyptus.

Example 4

An embodiment of the present invention, based on embodiments 1 to 3, implements that the BPH enters the blocking state, including the steps of:

step 1, software constructs the 'synchronization' relationship between processes;

and 2, under the condition that the BPH is not authorized by the MHT to use the HRU, the BPH applies the MHT for the permission of using the HRU to enter the blocking state, and the MHT grants the HRID and the SKB to the BPH. If BPH has already obtained MHT and used HRU to enter the permission of the blocking state, enter step 3 directly;

step 3, the BPH sends an HSCBLK instruction to the HSC by using the HRID and the SKB acquired from the MHT;

and step 4, the HSCBLK instruction is executed by the HSC.

Example 5

An embodiment of the present invention, on the basis of embodiment 4, implements MHT to trigger a process in a blocking state in a designated HRU, including the steps of:

step 1, MHT sends HSCMTRG instruction to HSC;

and step 2, the HSC executes an HSCMTRG instruction.

Example 6

An embodiment of the present invention, on the basis of embodiment 4, implements a process in which a PHT triggers and specifies a blocking state in an HRU, including the steps of:

step 1, under the condition that the PHT does not obtain the authorization of the MHT to trigger the HRU, the PHT applies to the MHT to obtain the authority of triggering the appointed HRU, and the MHT grants the HRID, namely SKT to the PHT. If the PHT has acquired the right to trigger the HRU, directly entering the step 2;

step 2, the PHT sends an HSCPTRG instruction to the HSC by using the HRID and the SKT acquired from the MHT;

and step 3, the HSC executes the HSCPTRG instruction.

It should be noted that the above embodiments can be freely combined as necessary. The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and decorations can be made without departing from the principle of the invention, and these modifications and decorations should also be regarded as the protection scope of the present invention.

Claims

1. The hardware module structure for realizing the application requirement of software 'synchronization' is characterized in that:

a hardware module HSC is realized in the processor, and kernel hardware establishes physical interconnection through a bus controller in the processor;

and/or

When the software role MHT finishes the requirement of the 'synchronization' application, a relevant instruction for finishing the 'synchronization' operation needs to be sent to the HSC;

and/or

When the software role OS meets the requirement of the 'synchronization' application of other software roles, a related instruction for completing 'synchronization' safety setting needs to be sent to the HSC;

and/or

When the software role PHT finishes the requirement of the 'synchronization' application, a related instruction for finishing the 'synchronization' operation needs to be sent to the HSC;

the BPH software role needs to send relevant instructions to the HSC for completing the "sync" operation when it is needed to complete the "sync" application.

2. A data structure implementing a hardware synchronization resource HRU according to claim 1, characterized in that:

the data structure of the HRU contains the necessary information of the PIDM;

the data structure of the HRU contains the necessary information of SKT;

the data structure of the HRU contains the necessary information of the SKB;

the data structure of the HRU contains the necessary information for the BPE.

3. According to claim 1 and claim 2, a control method for safe operation of HSCs is implemented, characterized in that:

is executed in software and only the OS is able to execute the HSCSKH instruction.

4. According to claims 1 to 3, a control method for safe operation of HSCs is implemented, characterized in that:

is executed in software and only the MHT is able to execute the HSCSETM instructions.

5. According to claims 1 to 4, a control method for safe operation of HSCs is realized, characterized in that:

is executed in software and only the MHT is able to execute the HSCSKT instructions.

6. According to claims 1 to 4, a control method for safe operation of HSCs is realized, characterized in that:

is executed in software and only the MHT is able to execute the hscsbb instructions.

7. The implementation of BPH to perform "synchronous blocking" operations according to claim 6, characterized by:

BPH executes the HSCBLK instruction in the kernel.

8. According to claims 1 to 4, implementing MHT to complete "MHT triggered" operations, characterized by:

the MHT executes the HSCMTRG instruction in the kernel.

9. According to claim 5, the PHT is implemented to complete the "PHT trigger" operation, characterized in that:

the PHT executes HSCPTRG instructions in the kernel.

10. According to claim 1 and claim 2, the OS is implemented to perform an "OS triggered" operation, characterized in that:

the OS executes the hsctrg instruction in the kernel.