JP2012226709A - Exclusive control device and microcomputer - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an exclusive control device capable of reducing priority inversion among threads to the minimum or capable of giving priority to a specific core.SOLUTION: There is provided an exclusive control device 100 which includes priority registers 21 which are disposed being associated with plural processor elements, flag state holding means 23 which are disposed to each of the priority registers, a priority comparison circuit 22 that compares the priority set to the priority registers and locks the flag state holding means corresponding to the priority register to which the highest priority is set, and a highest priority register 24 that stores the highest priority in the priorities set to the priority registers.

Description

  The present invention relates to an exclusive control device capable of exclusive control of a shared resource, and more particularly to an exclusive control device that allows a plurality of processor elements to perform processing using a shared resource within an execution time.

  When a multi-core processor executes several threads in parallel, a plurality of cores may use shared resources. Conventionally, a method for exclusive control of various shared resources is known.

  A common approach is to use flags. A common flag is provided for the shared resource, and the thread A checks the state of the flag before using the shared resource. If the flag is released, the thread A turns on the flag so that the other thread B can share the shared resource. Prohibit the use of and use this shared resource. Thus, occupying a shared resource is called a lock.

  When thread A finishes using the shared resource, it turns off the flag and releases the shared resource. As a result, the thread B can use the shared resource. Such lock processing is generally handled by software that arbitrates contention for a shared resource such as an OS.

  Thread B waits until thread A locks the shared resource and is used and released. One mode in which thread B waits for the release of a shared resource is a spin lock system in which thread B repeatedly checks the flag state. In the spin lock method, thread B is executing only for flag monitoring until a lock is acquired. It is also unclear for thread B when thread A will release the lock. For this reason, even if the core executes the thread B, no processing result can be obtained, and the worst execution time of the thread B cannot be guaranteed.

  Therefore, a technique for shortening the spin time has been proposed (see, for example, Patent Document 1). In Patent Document 1, when the information processing unit fails to acquire the lock, the lock continuation time of the preceding lock acquisition information processing unit is compared with the determination threshold time, and the lock waiting operation is selected according to the comparison result. Is disclosed.

JP 2010-191575 A

  However, the technique as in Patent Document 1 has a disadvantage that it requires software. In other words, although an atomic instruction is required to realize spin lock by software, not all CPUs can execute the atomic instruction. This is because the hardware side (CPU side) needs to correspond to the implementation of the atomic instruction, and more specifically, a complicated bus mechanism corresponding to the atomic instruction is required, which increases the cost. For this reason, some CPUs may not be able to realize a spin lock in software.

  Therefore, a multi-core system is required to have a dedicated hardware for guaranteeing the worst execution time and realizing a spin lock even in a CPU not mounting an atomic instruction.

  FIG. 1 shows an example of a configuration diagram of spin lock hardware. Spinlock hardware has a dedicated priority register for each core, a priority comparison circuit set in each priority register, and a dedicated lock acquisition for each core that specifies the core that acquired the lock based on the comparison result Has a flag.

  The spin lock hardware is a queue in order of priority (queuing) in which each core spins until each core can lock the shared resource by setting the priority in the priority register. Such spin lock hardware is sometimes referred to as queuing spin lock hardware.

However, the spin lock hardware as shown in FIG. 1 has the following disadvantages.
(1) Inheritance of thread priority is difficult FIG. 2 is an example of a diagram illustrating thread priority. For example, the core 0 executes the thread A included in the application 0 and the thread a called from the thread A, and the core 1 executes the thread B included in the application 1. Thread A uses shared resource R1, and thread a and thread B use shared resource R2. The priority among threads is as follows.
Thread A> Thread B> Thread a
When the core 0 sets the priority of the thread A in the priority register, since the thread A has a higher priority than the other threads, the shared resource R1 can be locked. Thereafter, since core 0 executes thread a, core 0 sets the priority of thread a in the priority register, and core 1 executes thread B. Therefore, core 1 sets the priority of thread B to priority. May be set in registers. If the shared resource R2 is released, the priorities of the thread a and the thread B are compared. However, since the thread B has a higher priority than the thread a, the thread B locks the shared resource R2. End up.

  That is, the thread A needs the execution result of the thread a for processing. However, since the thread B has a higher priority than the thread a, the thread A must wait for the processing of the thread B having a lower priority. Don't be. Such a priority inversion phenomenon occurs because there is no mechanism for specifying the highest priority core of the shared resource R1 and succeeding to the priority of the shared resource R2. However, since there is no mechanism for inheriting the priority in the spin lock hardware, the worst execution time of the thread A having a high priority may not be guaranteed. This can be realized by combining software as described above, but it is practically difficult to realize because the software overhead for realizing the spin lock capable of inheriting the priority is large.

(2) No mechanism for prioritizing a specific core In the priority register, for example, a thread sets a priority, and the priority of each thread is compared. For this reason, in principle, the shared resources can be locked in order from the set cores with higher priorities (or smaller cores).

  However, when a thread executed by a certain core is a special thread that is activated only in an emergency, it may be preferable that the core executing the thread has priority over the core executing the thread of a general application. In such a case, it is difficult for the spin lock hardware of FIG. 1 to prioritize a specific core.

  In view of the above problems, an object of the present invention is to provide an exclusive control device capable of reducing the priority inversion phenomenon between threads as much as possible or giving priority to a specific core.

  The present invention compares a priority register arranged in association with a plurality of processor elements, a flag state holding unit arranged for each of the priority registers, and a priority set in the priority register. A priority comparison circuit for setting a lock state in the flag state holding means corresponding to the priority register for which a high priority is set, and the highest priority among the priorities set in the priority register are stored An exclusive controller having a highest priority register is provided.

  It is possible to provide an exclusive control device capable of reducing the priority inversion phenomenon between threads as much as possible or giving priority to a specific core.

It is an example of the block diagram of a spin lock hardware. It is an example of the figure explaining the priority of a thread. It is an example of the hardware block diagram of a microcomputer. It is an example of the block diagram of a spin lock hardware. It is an example of the figure explaining the effect | action of a spin lock hardware. It is an example of the functional block diagram of each function which operates spin lock hardware. FIG. 10 is an example of a flowchart showing a procedure for operating the spin lock hardware mainly by the OS. FIG. 3 is an example of a configuration diagram of spin lock hardware (Example 2); FIG. 10 is a flowchart illustrating an example of an OS processing procedure when “1” is set in a local priority bit.

  Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings.

  FIG. 3 shows an example of a hardware configuration diagram of the microcomputer. The microcomputer 200 may be mounted in any state, such as a one-chip microcomputer, a microcomputer in which a CPU or the like is on a separate chip on the substrate.

  The illustrated microcomputer 200 is assumed to be mounted on an ECU (Electronic Control Unit), but its application is not limited to a vehicle. In addition to the microcomputer 200, the ECU is mounted with an input channel for receiving sensor signals and its driver, a monitoring IC for the microcomputer 200, a power supply IC, and the like.

  There are various types of ECUs mounted on the vehicle, such as an engine ECU, a brake ECU, a body ECU, a navigation ECU (AV / information processing ECU), and a gateway ECU, depending on main functions. The microcomputer 200 of the present embodiment can be mounted without being affected by the difference in ECU functions. Further, in recent years, attempts have been made to integrate a plurality of functions into one ECU, so that the necessity of distinguishing the ECU on which the microcomputer 200 is mounted by function is low.

  The microcomputer 200 includes a CPU 11, a ROM 12, a spin lock hardware 100, an INTC 13, a RAM 14, a DMAC 15, and an I / O bridge 16 connected to a bus, and an ADC 17 and a CAN controller 18 are connected to the I / O bridge 16. Has been.

  The CPU 11 includes a plurality of cores 0 to n, and the core 0 and the core 1 are illustrated in the drawing, but may include three or more cores. The cores 0 and 1 use the local RAMs 0 and 1 as work memories, respectively. Note that, instead of the multi-core type, one CPU may have a virtual CPU that makes it appear that a plurality of CPUs exist by executing instructions in parallel while switching registers and arithmetic units. A plurality of independent CPUs may be mounted as chips. A plurality of cores and a plurality of independent CPUs may be referred to as processor elements.

  The ROM 12 is a nonvolatile memory such as a flash memory, and stores programs executed by the CPU 11 and static data. The program stores an application 0 executed by the core 0, an application 1 executed by the core 1, and an OS and a device driver. There is a concept of a thread or task in which an application is divided into smaller granularities. In this embodiment, a thread or task is extracted from the application as appropriate. For ease of explanation, the relationship between each application and each core is assumed to be fixed. However, for example, an OS or the like can dynamically assign an application to a core. In this case, since the OS stores the correspondence between the core and the application, there is little inconvenience for the OS depending on whether or not the relationship between each application and each core is fixed.

  The INTC 13 arbitrates based on the priority of the peripheral device and notifies the CPU 11 of the interrupt request input from the peripheral device via the IRQ or other interrupt terminal. As a result, the CPU 11 executes processing determined according to the interrupted peripheral device.

  The RAM 14 is a work area for the CPU 11 to execute a program. The CPU 11 reads the program from the ROM (or SDRAM when the program is moved to the SDRAM for execution) via the memory bus, and reads the data from the RAM 14 via the data bus if necessary and executes the program.

  The DMAC 15 transmits data from the RAM 14 to the peripheral device via the I / O bridge 16 according to an instruction from the CPU 11, receives an instruction from the CPU 11 interrupted by the peripheral device, and receives data from the peripheral device via the I / O bridge 16. Data is received and written to the RAM 14.

  The I / O bridge 16 is a multiplexer or a bridge circuit, and is connected to the ADC 17 and the CAN controller 18 for each channel, and transmits / receives data to / from these peripheral devices. An ADC (analog to digital converter) 17 converts an analog signal detected by the sensor into a digital signal. The ADC 17 includes a ΔΣ type, a successive approximation type, a double integration type, and the like, but may be converted by any conversion principle. The ADC 17 also notifies the CPU 11 of the end of conversion via the INTC 13.

  The CAN controller 18 is a communication device for communicating with other ECUs connected via an in-vehicle network. When receiving a communication data transmission request from the CPU 11, the CAN controller 18 stores the ID and data in each field of the frame and outputs them to the CAN bus. Further, when the CAN controller 18 detects the communication data of the ID to be received, it captures it and interrupts it to notify the CPU 11.

  In FIG. 3, among peripheral devices used by applications, peripheral devices used by a plurality of applications are shared resources. For example, it is assumed that the ADC 17 and the CAN controller 18 are shared resources R1 and R2, respectively.

  The spin lock hardware 100 (hereinafter referred to as “spin lock hardware 1, 2... When distinguished”) is arranged for each shared resource. That is, the spin lock hardware 1 is for the ADC (shared resource R1), the spin lock hardware 2 is for the CAN controller 18 (shared resource R2), the spin lock hardware 3 is ... Lock hardware is associated. In order for the core to use the shared resource, the shared resource R1 must be locked by the spin lock hardware 1, and the shared resource R2 must be locked by the spin lock hardware 2.

  FIG. 4 shows an example of a configuration diagram of the spin lock hardware 100 of the present embodiment. The spin lock hardware 100 is characterized in that it can inherit the priority of a nested thread.

  First, the spin lock hardware 100 includes a dedicated priority register 21 for each core (priority registers 0, 1,..., N when distinguished), a priority comparison circuit 22 set in each priority register 21, Each core that designates the core that has acquired the lock based on the comparison result has a dedicated lock acquisition flag 23 (in the case of distinction, the lock acquisition flags 0, 1,... N), and the highest priority register 24. The priority of each thread executed by each core is set in each priority register 21. Each priority register 21 is connected to a comparison circuit 22. The comparison circuit 22 is connected to each lock acquisition flag 23 and also connected to the highest priority register 24. The state of the lock acquisition flag 23 and the contents of the highest priority register 24 can be read from the outside.

  The comparison circuit 22 specifies the priority register in which the highest priority is set among all the priority registers 0 to n. In this embodiment, the higher the numerical value, the higher the priority, but the reverse may be possible. The comparison circuit 22 sets “1” to the lock acquisition flags 0 to n corresponding to the priority registers 0 to n for which the highest priority is set. Therefore, the cores 0 to n corresponding to the lock acquisition flags 0 to n in which “1” is set can lock the shared resource locked by the spin lock hardware 100 (the use right has been obtained).

  Further, the comparison circuit 22 sets the value of the priority register 21 in which the highest priority among the priority registers 0 to n is set in the highest priority register 24. The highest priority register 24 always stores the highest priority in the spin lock hardware 100.

  FIG. 5 is an example of a diagram for explaining the operation of the spin lock hardware 100. As shown in FIG. 5A, it is assumed that the priority of the core 0 is “00001111” and the priority of the core 1 is “00000011”. The priority set is, for example, a counter value that is treated as a time stamp. If the higher the numerical value, the higher the priority, the counter decreases uniformly from a certain set value. Further, when the priority is higher when the numerical value is lower, the counter increases uniformly. Therefore, in any case, the core whose value is set by reading the numerical value from the counter earlier is given priority. In addition, since the core whose priority is set first is given priority, the spinlock hardware 100 becomes a FIFO type queue (queuing).

  The comparison circuit 22 sets the lock acquisition flag 0 of the core 0 set with the highest priority to “1”. The comparison circuit 22 clears the lock acquisition flag 1 of the cores 1 other than the core 0 to “0”. Of the lock acquisition flags 0 to n, only one outputs “1”. Further, the comparison circuit 22 acquires “000011111” which is the highest priority among the priorities of the cores 0 and 1 and stores it in the highest priority register 24.

  Next, the core 0 finishes the process of using the shared resource, and sets zero in the priority register 1. As a result, the comparison circuit 22 sets the lock acquisition flag 1 of the core 1 with the highest priority set to “1”, and clears the lock acquisition flag 0 of the core 0 to “0”. The comparison circuit 22 acquires “00000011” which is the highest priority among the priorities of the cores 0 and 1 and stores it in the highest priority register 24.

  With this action of the spin lock hardware 100, the OS can specify the core to which the shared resource should be locked, and if the thread has a nested structure of two or more stages, the priority is given to the second and subsequent threads. Can be inherited.

  FIG. 6 is an example of a functional block diagram of each function for operating the spin lock hardware 100. When each of the applications 1 and 2 freely operates the spin lock hardware 100, a conflict occurs at this point, and therefore, specific software such as an OS generally operates the spin lock hardware 100 (for example, in a privileged mode).

  Assume that core 0 executes application 0 and core 1 executes application 1 in units of threads. Each of the applications 0 and 1 includes a lock request unit 31, a resource handling processing unit 32, and a lock release request unit 33.

  Each thread executes a predetermined command in order to acquire (lock) the shared resource R1 or R2 when using the shared resource R1 or R2. That is, it requests the OS to lock. What kind of command is different depending on the instruction set of the CPU 11, for example, “get_resorce resource name” is known. The lock request unit 31 issues such a command immediately before using the shared resources R1 and R2. Such a command is a kind of system call for calling the OS. Thereafter, the core that requested the lock enters a spin lock state until the lock can be acquired.

  The core that has acquired the lock ends the spin lock state, and the resource handling unit 32 of the core that has acquired the lock executes processing using the shared resource R1 or R2. When the resource handling processing unit 32 finishes executing the processing using the shared resource R1 or R2, the lock release requesting unit 33 releases (unlocks) the shared resource R1 locked by the core. Run. The type of command differs depending on the instruction set. For example, “release_resorce resource name” is known. Thereafter, the core that has requested the release of the lock executes processing according to the program.

  The OS includes a priority setting unit 35, a nest determination unit 36, a flag reading unit 37, and a highest priority register reading unit 38. When receiving a lock request from the lock request unit 31, the priority setting unit 35 sets the priority in the priority registers 0 to n corresponding to the cores 0 to n. The priority may be specified by a thread, determined for each thread, or dynamically determined by the OS in consideration of the thread. In this embodiment, it is assumed that a thread specifies. Therefore, the priority setting unit 35 sets the priority specified by the thread that requested the lock in the priority registers 0 to n corresponding to the cores 0 to n executing the thread.

  When the lock release requesting unit 33 requests the shared resource R1 or R2 to be unlocked, the priority setting unit 35 has the highest priority in the priority registers 0 to n corresponding to the cores 0 to n that requested the unlocking. Set a small value (eg, zero). As a result, the lock of the shared resource is unlocked.

  The flag reading unit 37 updates the lock variable. As shown in the figure, the lock variable is provided for each of the cores 0 to n and for each of the shared resources R1 and R2. The flag reading unit 37 identifies the shared resource R1 or R2 depending on the spin lock hardware, and sets the lock variable of the cores 0 to n corresponding to the lock acquisition flags 0 to n that output “1” to “1”. To do. In addition, the flag reading unit 37 sets all lock variables other than the core set to “1” to “0”. In this way, only one lock variable is set to “1” for one shared resource. The resource handling unit 32 uses the shared resource only when the lock variable of the core executing the thread is “1”, and spin-locks when the lock variable is “0”.

  The nest determination unit 36 determines whether the lock request requested by the lock request unit 31 is a lock request for a thread nested in two or more stages. Nesting means nesting, and another thread or routine is inserted into one thread or routine. Specifically, the thread A in FIG. 2 has a nested structure, and the thread a is nested in the thread A. Here, the thread nested in two or more levels corresponds to the thread a.

  After the core executing the thread A locks the shared resource R1, there is a case where another core resource R2 is requested to be locked because of the nested thread a. For example, this may occur when the thread A has a close relationship such as using the processing result of the thread a, and the thread A and the thread a use different shared resources R1 and R2. The nest determination unit 36 detects a lock request requested by the thread a.

  For example, when receiving the lock request, the nest determination unit 36 specifies the shared resource R2 that has been requested to be locked. Then, it is determined whether “1” is set in the lock acquisition flags 0 to n corresponding to the cores 0 to n requested to be locked other than the spin lock hardware 2 of the shared resource R2 requested to be locked. The fact that “1” is set in the lock acquisition flags 0 to n means that the same core as that requested to lock the resource R2 has already locked another shared resource R1. In such a situation, there is a high possibility that there is a lock request for the thread a having two or more levels of nesting.

  Note that the nest determination unit 36 receives a lock request for a thread a nested in two or more levels based on a lock request from the lock request unit 31 that is explicitly locked in two or more levels. You may determine that there is.

  The nest determination unit 36 notifies the highest priority register reading unit 38 of the determination result determined as described above.

  The highest priority register reading unit 38 is a spin lock in which “1” is set in the lock acquisition flags 0 to n corresponding to the cores 0 to n requested to be locked other than the spin lock hardware of the shared resource requested to be locked. The value of the highest priority register 24 of the hardware 1 is read. As a result, the priority set by the cores 0 to n that requested the lock (the highest highest priority in the spin lock hardware 1) can be acquired.

  The highest priority register reading unit 38 notifies the priority setting unit 35 of the highest priority of the spin lock hardware 1. The priority setting unit 35 sets the highest priority in the priority registers 0 to n corresponding to the cores 0 to n of the spin lock hardware 2 of the shared resource R2 requested to be locked by the thread a. That is, the highest priority is set instead of the priority notified to the OS together with the lock request by the thread a. By setting the highest priority in the priority register 21 of the second-stage spinlock hardware 2 instead of the priority requested by the thread a together with the lock request, the priority of the thread A being executed by the core is It is succeeded as the priority of the thread a.

[Operation procedure]
FIG. 7 is an example of a flowchart diagram illustrating a procedure in which the OS mainly operates the spin lock hardware 100.

  First, the priority setting unit 35 acquires a lock request and priority together with the designation of the shared resource A from the lock request unit 31 of the thread A of the application 0 (S10). Actually, first, the nest determination unit 36 first determines whether or not it is a lock request for the thread a nested in two or more stages, but this is omitted here.

  Next, the priority setting unit 35 sets priorities in the priority registers 0 to n corresponding to the cores 0 to n requested to be locked in the spin lock hardware 1 corresponding to the shared resource R1 (S20).

  Thereafter, the flag reading unit 37 monitors the lock acquisition flags 0 to n of the spin lock hardware 1, and determines whether or not the core executing the thread A has acquired the lock (S30). For example, if another core has already locked the shared resource R1, the core that requested the lock is spin-locked until the shared resource R1 is released by terminating a thread executed by the other core.

  When the thread A acquires the lock (Yes in S30), the highest priority register reading unit 38 reads the value of the highest priority register 24 (S40). If the core from which the lock is acquired changes, the value of the highest priority register 24 also changes. Therefore, the highest priority may be acquired at a timing such as when the value of the highest priority register 24 is updated. The value of the highest priority register 24 allows the priority of the thread A to be inherited.

  Next, during execution of thread A, thread a nested in thread A is executed. Since the thread a requires the shared resource R2, the lock request unit 31 of the thread a notifies the priority setting unit 35 of the lock request and the priority together with the designation of the shared resource R2. Thereby, the priority setting unit 35 acquires the lock request and the priority together with the designation of the shared resource R2.

  Here, the nest determination unit 36 determines whether or not “1” is set in the lock acquisition flags 0 to n corresponding to the core that requested the lock, other than the spinlock hardware 2 of the shared resource R2 that is requested to be locked. By determining, it is determined whether to inherit the priority.

  When the priority should be inherited, the priority setting unit 35 sets the value of the highest priority register 24 read by the highest priority register reading unit 38 to the priority corresponding to the core executing the thread a of the spinlock hardware 2. The degree register 21 is set (S50). By doing so, the priority of the thread a becomes the same as that of the thread A.

  The flag reading unit 37 monitors the lock acquisition flags 0 to n of the spin lock hardware 2, and determines whether or not the core executing the thread a has acquired the lock (S60). If it cannot be acquired, a thread having a higher priority than the thread A uses the shared resource R2, and the core executing the thread a spin-locks. Therefore, the process returns to step S40.

  When the core executing the thread a acquires the lock of the shared resource R2 (S60), the flag reading unit 37 sets only the lock variable of the shared resource R2 of the core executing the thread a to “1”, and the like. Is set to “0”. As a result, the thread a can exclusively use the shared resource R2 (S70).

  As described above, the spin lock hardware 100 according to the present embodiment can realize the spin lock in hardware even when the CPU 11 does not have an atomic instruction. Even if the thread has a nested structure, the second-stage thread can take over the priority of the first-stage thread, so that the worst execution time of the thread having the nested structure can be guaranteed.

  In the present embodiment, a spin lock hardware 100 that can selectively give priority to any of the cores 0 to n will be described.

  FIG. 8A shows an example of a configuration diagram of the spin lock hardware 100 of the present embodiment. In FIG. 8, the same parts as those in FIG. The spin lock hardware 100 has a local priority bit for each core, and is characterized in that a specific core can be prioritized.

  FIG. 8B shows an example of local priority bits. The local priority bit is the first bit of the priority register 21. That is, if the number of bits of the priority register 21 is 8, the priority is set to the lower 7 bits of the priority register 21, and the local priority bit is assigned to the most significant bit (MSB).

As in the first embodiment, the comparison circuit 22 compares the “local priority bit + priority” of each of the cores 0 to n and sets the lock acquisition flags 0 to n of the cores with the largest value to “1”. . As a result, the spin lock hardware 100 operates as follows.
Unless the cores 0 to n preferentially lock the shared resource, the local priority bit is “0”, so that the cores 0 to n having the highest priority are preferentially shared as in the first embodiment. Resources can be used.
When one of the cores 0 to n preferentially locks the shared resource, the local priority bit is set to “1” because only the local priority bit of one priority register 21 is “1”. The core can use shared resources preferentially.
When any two or more of the cores 0 to n preferentially lock the shared resource, a plurality of local priority bits become “1”. In this case, among the plurality of cores having the local priority bit set to “1”, the core having the highest priority set in the lower 7 bits of the priority register can preferentially use the shared resource.

[Necessity of local priority bit]
When the cores 0 to n need to use the shared resource preferentially, in other words, the case where the certain cores 0 to n may preferentially use the shared resource is, for example, a fail-safe process when an abnormality is detected High-priority interrupt processing, OS specific management software processing, and the like.

  In addition, for example, a thread that is waiting (spinning) until the shared resource is released for a certain time or more may be able to set the local priority bit to “1”. This setting is preferably set autonomously when the priority setting unit 35 of the OS monitors a core that is spin-locked and a certain time or more has elapsed.

  However, even if each thread is allowed to set the local priority bit to “1”, the priority is compared by the lower 7 bits, so even if each thread sets the local priority bit to “1”. The priority will never be reversed.

[Operation procedure]
FIG. 9A shows an example of the OS processing procedure when the local priority bit is set to “0”, and FIG. 9B shows the OS processing procedure when the local priority bit is set to “1”. It is a flowchart figure which shows an example of a process procedure, respectively.

  In FIG. 9A, the priority setting unit 35 acquires the lock request and priority together with the designation of the shared resource A from the lock request unit 31 of the thread A (S10).

  Next, the priority setting unit 35 sets priorities in the priority registers 0 to n corresponding to the cores 0 to n requested to be locked in the spin lock hardware 1 corresponding to the shared resource R1 (S20). Here, the local priority bit is “0”.

  Thereafter, the flag reading unit 37 monitors the lock acquisition flags 0 to n of the spin lock hardware 1, and determines whether or not the core executing the thread A has acquired the lock (S30).

  If it cannot be acquired, a thread having a higher priority than the thread A uses the shared resource R1, and the core executing the thread A spin-locks. For this reason, a process returns to step S30.

  When the thread A acquires the lock (Yes in S30), the thread A can exclusively process using the shared resource R1 (S70).

  Subsequently, in FIG. 9B, the priority setting unit 35 acquires the lock request and the priority along with the designation of the shared resource A from the lock request unit 31 of the thread A of the application 0 (S10).

  Next, the priority setting unit 35 sets the priority in the priority register corresponding to the core that requested the lock of the spin lock hardware 1 corresponding to the shared resource R1 (S22). Here, it is assumed that the thread A or OS sets the local priority bit to “1”. This increases the possibility that the thread A can preferentially lock the shared resource R1.

  Thereafter, the flag reading unit 37 monitors the lock acquisition flags 0 to n of the spin lock hardware 1, and determines whether or not the core executing the thread a has acquired the lock (S30).

  If it cannot be obtained, the thread having higher priority than the thread A uses the shared resource R1 with the local priority bit set to “1”, so the core executing the thread A is spin-locked. To do. For this reason, a process returns to step S30.

  When the thread A acquires the lock (Yes in S30), the thread A can exclusively process using the shared resource R1 (S70).

  The process of FIG. 9B is a process without nests (only the first stage), but the same applies when there are two or more levels of nests. That is, if the first-stage thread A sets the local priority bit to “1”, the second-stage thread a can also inherit this priority. When the first-stage thread A sets the local priority bit to “0”, and the second-stage thread a sets the local priority bit to “1” (the relationship between such priorities is usually The priority setting unit 35 does not set the priority of the second-stage thread a in the priority register 21, so the priority of the first-stage thread A is inherited.

  As described above, in addition to the effects of the first embodiment, the spin lock hardware of this embodiment can cause a specific core to preferentially lock a shared resource and execute processing.

11 CPU
12 ROM
13 INTC
17 ADC
18 CAN controller 21 priority register 22 comparison circuit 23 lock acquisition flag 24 highest priority register 100 spin lock hardware 200 microcomputer

Claims (7)

A priority register arranged in association with a plurality of processor elements;
Flag state holding means arranged for each of the priority registers;
A priority comparison circuit that compares the priority set in the priority register and sets a lock state in the flag state holding unit corresponding to the priority register in which the highest priority is set;
An exclusive control device comprising: a highest priority register for storing the highest priority among the priorities set in the priority register. The priority register has a reserved bit, and the priority of the priority register in which a predetermined value is set in the reserved bit is higher than the priority of the priority register in which the predetermined value is not set.
The exclusive control apparatus according to claim 1.   3. The exclusive control apparatus according to claim 2, wherein the reserved bit of the priority register is a most significant bit. The highest priority stored in the highest priority register is set in the priority register associated with the processor element that has set the highest priority of another exclusive control device.
The exclusive control apparatus according to any one of claims 1 to 3, wherein Multiple processor elements;
Multiple peripherals,
A plurality of exclusive control devices according to any one of claims 1 to 4, arranged corresponding to the peripheral devices,
A microcomputer having Lock permission means for allowing the processor element associated with the flag state holding means in the locked state to lock the shared resource corresponding to the exclusive control device provided with the flag state holding means;
The microcomputer according to claim 5, comprising: The priority set by the predetermined processor element in the priority register of the first exclusive control device is stored in the highest priority register,
When the predetermined processor element sets a priority in the priority register of the second exclusive control device,
Priority setting means for setting the highest priority stored in the highest priority register of the first exclusive control device in the priority register associated with the predetermined processor element of the second exclusive control device Having
The microcomputer according to claim 5 or 6.

Images