JP2010026575A - Scheduling method, scheduling device, and multiprocessor system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently prevent deadlock in a multiprocessor system. <P>SOLUTION: A real time system 100 equipped with a CPU 110 and a CPU 150 performs exclusive control of a shared resource by a priority sealing system. A thread which has made a request for acquiring a shared resource to be shared by the CPU 110 and the CPU 150 acquire the shared resource under such conditions that the priority sealing value of the shared resource is larger than any priority sealing value of the shared resource during exclusive control by the thread in any CPU other than the CPU executing the thread by referring to shared resource acquisition information 210 stored in a shared memory 200. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to scheduling, particularly scheduling technology in a multiprocessor system.

A unit of sequential processing executed in the real-time system has a name such as “thread” or “task”, and is referred to as “thread” in this specification. Many real-time OSs (operating systems) support a preemptive priority-based scheduling policy as a scheduling policy for ensuring real-time performance. This scheduling policy is defined as follows.
1. The thread with the highest priority at that time is executed.
2. The processing of the highest priority thread at that time must not be interrupted.
3. In the case of the same priority, the order of arrival is first. “First-come-first-served order” means the order in which threads have transitioned to an executable state.
4). When a thread with a high priority is in an executable state, the thread is switched to execute a thread with a high priority even during the processing of a thread with a lower priority than the thread.

  The “executable state” described above means a state that can be executed when there is no other preempted thread, or when the other preempted thread releases the execution right of a CPU (Central Processing Unit).

  In a real-time system, exclusive control of shared resources (hereinafter simply referred to as exclusive control) is performed in order to solve a collision problem of resources that can be shared by threads (hereinafter referred to as shared resources). FIG. 5 is a schematic diagram of exclusive control processing.

  As shown in FIG. 5, when operating a shared resource, a thread first issues a resource acquisition request (hereinafter also simply referred to as an acquisition request) to the OS. Then, if the operation of the shared resource is permitted from the OS in response to the resource acquisition request, the shared resource is operated, and after the operation is completed, a resource release request (hereinafter also simply referred to as a release request) is issued to the OS to execute the shared resource. To release. A period from when a thread acquires a shared resource to when the shared resource is released is referred to as a “block period”, and a state of the shared resource in the block period is referred to as “exclusive control”.

  The OS permits the resource operation to the thread that issued the shared resource acquisition request on the condition that the exclusive control is not being performed by another thread. Thereby, it is possible to avoid a plurality of threads from operating the shared resource at the same time.

  Here, an exclusive processing mechanism in a real-time system having a single processor core will be described. In the following, “H”, “M”, and “L” are added to the notation of a thread to indicate that the priority of the thread is “high”, “medium”, and “low”.

  Many real-time OSs are equipped with a semaphore as an exclusive processing mechanism that can easily solve the shared resource collision problem. The semaphore includes a counting semaphore that takes a non-negative integer and a binary semaphore that takes “0” and “1”. The binary semaphore will be described below as an example. A section that requires exclusive processing, such as operating a shared resource, is called a critical region.

The following conventions have been established for using semaphores.
1. Take a semaphore when a thread enters a critical region.
2. While there is no semaphore, no other thread can enter the critical region.
3. If the semaphore is taken by another thread, wait until the semaphore returns.
4). Return semaphore when exiting critical region.
5). It is executed indefinitely (without thread switching) while taking a thread.
6). It is inseparably executed while returning the semaphore.
7). If there is a thread waiting when returning the semaphore, the waiting state of the thread is released.

  FIG. 6 shows a thread execution pattern in a real-time system using a semaphore. In the figure, the thread L1 having the priority “L: Low” issues an acquisition request to the OS, acquires a semaphore, and performs resource operations. Thereafter, it is a block period until the thread L1 issues a release request to the OS and returns the semaphore. In this period, other threads cannot take the semaphore of the shared resource. At time t0, since the thread M1 having the priority “M: medium” has changed to an executable state, the execution of the thread L1 is interrupted and the thread M1 is executed. At time t1, the thread M1 issues an acquisition request, but since the semaphore is under exclusive control by the thread L1, the thread M1 is suspended and the thread L1 is resumed. Later, when the thread L1 releases the semaphore, the thread M1 finally acquires the semaphore. Along with this, the thread M1 is executed and the thread L1 is interrupted.

  Hereinafter, waiting for a semaphore by a thread is referred to as “exclusive waiting”, and a section waiting for exclusion such as time t0 to time t1 illustrated in FIG. 6 is referred to as “exclusive waiting period”.

With reference to FIG. 7, a problem of deadlock occurs when a semaphore is used.
As shown in the example of FIG. 7, first, the thread L1 acquires the semaphore of the resource A that is a shared resource and operates the resource A. At time t0, since the thread M1 has transitioned to an executable state, the thread M1 is executed and the thread L1 is interrupted. At time t1, the thread M1 acquires a semaphore of resource B, which is another shared resource, and operates resource B. At time t2, the thread M1 requests the semaphore of the resource A to operate the resource A. However, since the semaphore of the resource A is owned by the thread L1, the thread M1 is suspended and waits for exclusion. Enter the period. Therefore, execution of the thread L1 is resumed.

The processing further proceeds, and the thread L1 requests the semaphore of the resource B to operate the resource B. However, since the semaphore of the resource B is owned by the thread M1, the thread L1 is also interrupted and enters the exclusion waiting period.
If this happens, neither thread M1 nor thread L1 can be executed, and so-called deadlock occurs.

  In order to solve the problem of deadlock that occurs when using a semaphore, there is a method using a priority sealing method that temporarily raises the priority of a thread that has acquired a semaphore.

  In the priority ceiling scheme, when a thread acquires a semaphore of a resource under the preemptive priority-based scheduling policy, the priority of the thread is immediately set to the priority ceiling value of the resource (hereinafter simply referred to as a ceiling value). It is a method of raising temporarily. This will be described with reference to FIG. The ceiling value is a priority that is equal to or higher than the priority of all threads that may acquire the resource, and is set in advance for the resource. Further, it is defined that a thread cannot acquire a resource having a ceiling value lower than its own priority (priority when the priority is temporarily listed).

  In the example of FIG. 8, the ceiling value of resource A and the ceiling value of resource B are “high”. As shown in the figure, at time t0, the operating thread L1 acquires the semaphore of resource A and operates resource A. Accordingly, the priority of the thread L1 is changed to the ceiling value “high” of the resource A.

  At time t1, the thread M1 transitions to the executable state, but the thread M1 cannot be operated because the thread L1 whose priority has been changed to “high” is operating. The thread L1 acquires the semaphore of resource B at time t2, and releases the semaphore of resource B at time t3.

  At time t4, the thread L1 releases the semaphore of resource A. At the same time, the priority returns to the original “low”. Thereby, since the priority of the thread M1 becomes higher than the priority of the thread L1, the thread M1 is executed and the execution of the thread L1 is interrupted.

  Thereafter, the thread M1 performs processing such as acquiring and manipulating the semaphore of the resource A. While the thread M1 is being executed, the thread L1 is not executed.

  In the example shown in FIG. 8, the ceiling value of resource A and resource B is the same “high”, but the ceiling value of resource A is “high” and the ceiling of resource B is “medium”. When the thread L1 acquires the semaphore of the resource A and the priority is changed to “high”, the resource B is not acquired.

  Thus, if the priority ceiling method is used, deadlock can be avoided in a real-time system of a single core processor. Further, since the time during which the thread exclusively controls the shared resource can be shortened, the efficiency of the entire system is improved.

  By the way, in a real-time system of a multi-core processor, there is a possibility of deadlock even if the priority sealing method is applied to a shared resource that can be shared by a plurality of processor cores. This will be described with reference to FIG.

  In FIG. 9, the vertical axis indicates the priority. Assume that there are two processor cores, processor core A and processor core B, and two resource A and resource B as shared resources. In addition, the ceiling value of both resource A and resource B is “high”.

  In the example of FIG. 9, first, the thread L1 being executed by the processor core A acquires a semaphore of the resource A in order to operate the resource A. As a result, the priority of the thread L1 is temporarily changed to the ceiling value “high” of the resource A.

  During the operation of the resource A by the thread L1 operating with the priority “high”, the thread M1 transitions to an executable state. At this time, since the processor core B is free, the thread M1 is executed by the processor core B. Then, the thread M1 acquires the semaphore of the resource B in order to operate the resource B. As a result, the priority of the thread M1 is temporarily changed to “high” in the ceiling value of the resource B.

  The processing continues, and the thread L1 that is operating the resource A further issues a semaphore acquisition request for the resource B. At this time, since the semaphore of the resource B is owned by the thread M1, the thread L1 is interrupted and waits for exclusion.

Thereafter, the thread M1 that is operating the resource B further issues a semaphore acquisition request for the resource A. Since the semaphore of the resource A is owned by the thread L1, the execution of the thread M1 is also interrupted and waits for exclusion.
If this happens, neither thread H1 nor thread M1 can be executed, and a deadlock occurs.

  In this way, in a real-time system using a multi-core processor, multiple threads with different priorities can operate at the same time, so priority sealing using the fact that low priority threads are not executed during execution of high priority threads Even if the method is applied, deadlock may occur.

  Various attempts have been made to eliminate the deadlock problem in multi-core processor systems. For example, the technique disclosed in Patent Document 1 includes an exclusive control management table that stores the name of a thread that is currently under exclusive control and the name of a thread that is waiting for exclusion for each shared resource, and a share that is currently under exclusive control for each thread. An exclusive control shared resource information table storing resource names is provided.

  When a thread makes a shared resource acquisition request, the exclusive control management table and the exclusive control shared resource information table are referred to determine whether the acquisition request causes a deadlock, and a deadlock occurs. If it is determined, the shared resource acquisition request is not made at that time.

  Specifically, when a system call requesting acquisition of a shared resource is issued from a certain thread, the name of the shared resource being controlled exclusively by the thread is read from the thread's exclusive control shared resource information table and exclusive control management is performed. From the table, the name of the thread that is currently exclusively controlling the shared resource requested by the thread is read. Further, for each shared resource read from the exclusive control shared resource information table, the names of threads waiting for exclusion of these shared resources are read from the exclusive control management table. Then, if both of the read thread names are compared and there is a matching thread name, it is determined that a deadlock will occur if an acquisition request is made as it is, and the exclusive control is currently being performed on the thread that has made the acquisition request. Control is performed so as to request acquisition of a shared resource to be used next after releasing the shared resource.

In other words, in response to a shared resource acquisition request from a thread, none of the threads waiting for exclusion of the shared resource under exclusive control by the thread is in the exclusive control of the shared resource that the thread is trying to acquire Control is performed so that the acquisition request can be issued only in By doing so, deadlock can be avoided even in a multi-core processor system.
JP-A-7-105152

  The technique of Patent Document 1 substantially attempts to solve the deadlock problem in a multi-core processor system using only a semaphore. When determining whether or not to issue a shared resource acquisition request, obtain the names of shared resources that are under exclusive control by the thread, acquire the names of threads that are waiting for exclusion of these shared resources, and share the acquisition request destination Processing such as acquisition of thread names during exclusive control of resources and comparison of acquired thread names is required. This complicates the shared resource exclusive control process and takes time.

  One aspect of the present invention is a scheduling method. In this method, in a multiprocessor system having shared resources that can be shared by a plurality of threads, exclusive control of these shared resources is performed by a priority ceiling method, and the shared resources are shared by a plurality of processor cores. For any thread that has requested acquisition of a shared resource between processors, the priority ceiling value of the shared resource between processors is between any processors that are under exclusive control by a thread in a processor core other than the processor core on which the thread operates. On the condition that the priority ceiling value of the shared resource is larger, the thread that issued the acquisition request acquires the inter-processor shared resource.

  An apparatus that executes the method of the above aspect, a multiprocessor system to which the method is applied, a program that causes a computer to execute the above method, an OS that includes the program, and the like are also effective as an aspect of the present invention. is there.

  According to the scheduling technique of the present invention, deadlock can be efficiently avoided in a multiprocessor system.

  Embodiments of the present invention will be described below with reference to the drawings. In addition, each element described as a functional block for performing various processes in the drawings used in the following description can be configured with a processor, a memory, and other circuits in terms of hardware, and in terms of software It is realized by a program recorded in a memory or loaded. Therefore, it is understood by those skilled in the art that these functional blocks can be realized in various forms by hardware only, software only, or a combination thereof, and is not limited to any one. Also, for the sake of clarity, only those necessary for explaining the technique of the present invention are shown in these drawings.

Before describing specific embodiments of the present invention, the principle of the present invention will be described first.
As described above, the priority sealing method is effective as a technique for avoiding deadlock in a single processor system. As a result of earnest research on exclusive control of these shared resources in a multiprocessor system having shared resources that can be shared by a plurality of processor cores, the present inventor has applied a priority ceiling method to exclusive control in a multiprocessor system. And established a method to improve the efficiency of exclusive control of shared resources.

  For easy understanding, the resources in the multiprocessor system are classified into three types. The first is a resource that is not shared by threads. Since it is not necessary to perform exclusive control for such resources, the handling of such resources is omitted in the following description.

  The second is a resource that can be shared only by a plurality of threads operating in the same processor core. Such resources are hereinafter referred to as “in-processor shared resources”.

  The third is a resource that can be shared by a plurality of processor cores. Such a resource may be operated by a plurality of threads respectively operating on different processor cores, and is hereinafter referred to as “interprocessor shared resource”.

  In the following description, the term “shared resource” simply means that both an inter-processor shared resource and an intra-processor shared resource are included.

  As described above, in a multiprocessor system, even when priority ceiling is applied to exclusive control of shared resources, deadlock can occur. As shown in FIG. 9, the thread L1 operating in the processor core A is under exclusive control of the inter-processor shared resource A (sealing value: H), and the thread M1 operating in the processor B is the inter-processor shared resource B (ceiling). When the value: H) is acquired, a deadlock occurs when the thread L1 and the thread M1 attempt to acquire the resource B and the resource A, respectively.

  That is, only by applying the priority ceiling method to exclusive control, a thread has the same ceiling value as that of the inter-processor shared resource during the exclusive control of one inter-processor shared resource by itself, A deadlock occurs if it is possible to acquire another inter-processor shared resource under exclusive control by a thread in the processor core.

  The technique established by the inventor of the present application has been made paying attention to this, and applies a priority ceiling method to exclusive control of a shared resource, and a thread that operates on a processor core in order to eliminate the above-mentioned possibility. Only when the sealing value of the inter-processor shared resource is larger than the sealing value of any inter-processor shared resource that is under exclusive control by a thread in another processor core Acquire the inter-processor shared resource.

  By doing so, for example, in the example of FIG. 9, since the thread M1 cannot acquire the resource B until the thread L1 releases the resource A, the deadlock does not occur.

  Compared to the case of a single-core processor, this method compares the ceiling value of the inter-processor shared resource requested by the thread with the ceiling value of the inter-processor shared resource that is under exclusive control by the thread in another processor core. Since only the work to be performed increases, processing is simple.

  The technology according to the present invention is particularly useful in a function-distributed multiprocessor system. In a function-distributed multiprocessor system, each thread operates only within one processor core defined for the thread. By applying the technology according to the present invention, it is possible to prevent a deadlock due to the acquisition of the inter-processor shared resource, so that each processor core is a single core unless a thread requests to acquire the inter-processor shared resource. It can be regarded as a processor, and for each processor core, scheduling similar to that of a single core processor can be performed, and the system can be easily constructed.

Based on the above principle, a specific embodiment of the present invention will be described.
FIG. 1 shows a real-time system 100 according to an embodiment of the present invention. The real-time system 100 includes a plurality of CPUs (two in the illustrated example: CPU 110 and CPU 150) and a shared memory 200 that can be accessed by each CPU via a bus 190.

  The CPU 110 includes a processor core 112, a scheduling unit 114, a plurality of threads (four in the illustrated example: threads 122 to 128) operating on the processor core 112, and a plurality of resources (four in the illustrated example: resource 132). , 134, 142, 144).

  The CPU 150 includes a processor core 152, a scheduling unit 154, a plurality of threads operating in the processor core 152 (four in the illustrated example: threads 162 to 168), and a plurality of resources (four in the illustrated example: resource 172). 174, 182, 184).

  The real-time system 100 is a function-distributed multiprocessor system. The threads 122 to 128 operate only on the processor core 112, and the threads 162 to 168 operate only on the processor core 152. Each thread has a priority set.

  The scheduling unit 114 performs scheduling for each thread that operates in the processor core 112, and the scheduling unit 154 performs scheduling for each thread that operates in the processor core 152.

  Among the resources in the CPU 110, the resource 132 and the resource 134 are shared resources within the processor that are shared only by threads that operate on the processor core 112, and the resources 142 and the resources 144 are limited to threads that operate on the processor core 112. In addition, it is an inter-processor shared resource that can be operated from a thread operating on the processor core 152.

  Among the resources in the CPU 150, the resource 172 and the resource 174 are shared resources within the processor that are shared only by threads that operate on the processor core 152, and the resource 182 and the resource 184 are limited to threads that operate on the processor core 152. In addition, it is an inter-processor shared resource that can be operated from a thread operating in the processor core 112.

  It should be noted that a resource that is not shared by threads does not need exclusive control, and therefore the description and illustration thereof are omitted.

  The shared memory 200 stores inter-processor shared resource acquisition information 210. As shown in FIG. 2, the inter-processor shared resource acquisition information 210 associates the ceiling value of the inter-processor shared resource under exclusive control with the identifier of the CPU on which the thread that acquired the inter-processor shared resource operates. Is.

  The shared memory 200 is an inter-processor shared resource shared by the CPU 110 and the CPU 150, and has the highest ceiling value.

  The scheduling unit 114 and the scheduling unit 154 have the same configuration and functions except that the target threads to be scheduled are different. Therefore, the scheduling unit 114 and the scheduling unit 154 will be described here with the scheduling unit 114 as a representative.

  The scheduling 114 performs scheduling for the threads 122 to 128 using a preemptive priority-based scheduling policy. For exclusive control of shared resources, the priority ceiling method is used. Specifically, when any thread operating on the processor core 112 acquires a shared resource, the priority of the thread is temporarily increased to the ceiling value of the acquired shared resource. Further, control is performed so that a running thread cannot acquire a shared resource having a ceiling value lower than the priority of the thread at that time.

  Further, the scheduling unit 114, when any thread operating in the processor core 112 acquires the inter-processor shared resource, includes each thread operating in the processor core 112 (including the thread that acquired the inter-processor shared resource). When there is no thread that has acquired another inter-processor shared resource having the same ceiling value as the inter-processor shared resource, the shared memory is associated with the ceiling value of the inter-processor shared resource and the identifier of the CPU 110. Write to 200. In addition, when a thread that has acquired an inter-processor shared resource releases the shared resource, an inter-processor shared resource having the same sealing value as that of the inter-processor shared resource is acquired from each thread operating in the processor core 112. If there is no thread, the item corresponding to the shared resource is deleted.

  As can be seen from the description below, when a thread in the CPU 110 issues an inter-processor shared resource acquisition request, the scheduling unit 114 determines whether to acquire the inter-processor shared resource. This is information indicating whether or not there is an inter-processor shared resource with a ceiling value equal to or higher than the ceiling value of the inter-processor shared resource requested to be acquired among the inter-processor shared resources under exclusive control. Therefore, even when there is a plurality of inter-processor shared resources that are under exclusive control by a thread in the CPU and have the same sealing value for one CPU, the inter-processor shared resource acquisition information 210 includes the ceiling value. There is no need to write the contents in which the sealing value and the CPU are associated with each other for all the inter-processor shared resources. By doing so, it is possible to save the capacity occupied by the inter-processor shared resource acquisition information 210 in the shared memory 200.

  When any thread operating in the processor core 112 requests acquisition of an inter-processor shared resource, the scheduling unit 114 refers to the inter-processor shared resource acquisition information 210 stored in the shared memory 200 and requests the requested processor. Decide whether to allow the thread to acquire shared resources. Specifically, the requested processor is acquired only when the ceiling value of the inter-processor shared resource requested to be acquired is larger than any of the ceiling values corresponding to the CPU 150 included in the inter-processor shared resource acquisition information 210. Make the thread acquire shared resources.

With reference to the flowchart shown in FIG. 3, the operation of the scheduling unit 114 will be described in more detail.
When a thread being executed in the processor core 112 requests acquisition of a shared resource (S100), the scheduling unit 114 checks whether the shared resource is an inter-processor shared resource (S110). If it is not an inter-processor shared resource, a resource acquisition process is performed in the CPU 110 (S110: No, S160). Since the resource acquisition process in the CPU 110 is the same process as when the CPU 110 is regarded as a single core processor, a detailed description thereof is omitted here.

  On the other hand, when the resource requested to be acquired is an inter-processor shared resource, the scheduling unit 114 refers to the inter-processor shared resource acquisition information 210 stored in the shared memory 200 and determines each thread operating on the processor core 112. In the meantime, it is confirmed whether there is a thread under exclusive control of another inter-processor shared resource having the same sealing value as the inter-processor shared resource (S110: Yes, S120, S130). Specifically, the confirmation in step S130 is the content stored in the inter-processor shared resource acquisition information 210 in association with the CPU 110 and the same ceiling value as the requested inter-processor shared resource. It is confirmation of the presence or absence.

  If the result of the confirmation in step S130 is “Yes”, the ceiling value of the inter-processor shared resource acquired by any thread in the other CPU (here, CPU 150) is the ceiling of the inter-processor shared resource requested to be acquired. Since the value is less than or equal to the value, the scheduling unit 114 performs a resource acquisition process in the CPU 110 that causes the thread that has requested acquisition to acquire the inter-processor shared resource (S130: Yes, S160).

  On the other hand, if the result of the confirmation in step S130 is “None”, the scheduling unit 114 further determines that the ceiling value of the inter-processor shared resource requested to be acquired is between any processors that are exclusively controlled by other CPUs. It is confirmed whether it is larger than the ceiling value of the shared resource (S130: No, S140).

  If an inter-processor shared resource having a ceiling value equal to or higher than the ceiling value of the inter-processor shared resource requested to be acquired is under exclusive control by another CPU (S140: Yes), the scheduling unit 114 causes the above CPU to execute the above processor. The inter-processor shared resource requested to be acquired is not acquired by the thread until the inter-shared resource is released (S140: Yes, S140). During this period, the scheduling unit 114 puts the processor core 112 into a state where it can be preempted by an interrupt. By doing this, when the thread cannot acquire the inter-processor shared resource and is waiting, the CPU 110 can cause the thread to be executed by the processor core 112 when another thread transitions to an executable state. it can.

  On the other hand, when the ceiling value of the inter-processor shared resource requested to be acquired is larger than the ceiling value of any inter-processor shared resource that is under exclusive control by another CPU, the scheduling unit 114 sends the inter-processor A resource acquisition process is performed in the CPU 110 for acquiring the shared resource, and the sealing value of the shared resource and the identifier of the CPU 110 are associated with each other and written to the shared memory 200 to update the inter-processor shared resource acquisition information (S140: No, S150, S160).

  The utility of the scheduling method in the real-time system 100 will be described using the operation example shown in FIG.

<Time t0>
In the CPU 110, the thread 122 having the priority “L” is executed, and the CPU 150 has no thread being executed.

<Time t1>
The thread 122 issues an acquisition request for the inter-processor shared resource 142 to acquire the inter-processor shared resource 142. Along with this, the priority of the thread 122 is changed to the ceiling value “H” of the inter-processor shared resource 142. In addition, the ceiling value “H” and the CPU 110 are written in the inter-processor shared resource acquisition information 210 in association with each other.

<Time t2>
In the CPU 150, the thread 162 is changed to the executable state, so that it is executed.

<Time t3>
In the CPU 150, the thread 162 requests acquisition of the inter-processor shared resource 144 having the ceiling value “H”. However, since the inter-processor shared resource acquisition information 210 has the ceiling value “H” stored in association with the CPU 110, the thread 162 cannot obtain the inter-processor shared resource 144 and enters a waiting state.

<Time t4>
In the CPU 110, the thread 122 issues an acquisition request for the inter-processor shared resource 144 to acquire the inter-processor shared resource 144.

<Time t5>
In the CPU 110, the thread 122 releases the inter-processor shared resource 144.
In the CPU 150, the thread 162 continues to wait.

<Time t6>
In the CPU 110, the thread 122 releases the inter-processor shared resource 142, and the priority returns to the original “L”. Along with this, the content in which the ceiling value “H” is associated with the CPU 110 is deleted from the inter-processor shared resource acquisition information 210.

  Therefore, in the CPU 150, the thread 162 acquires the inter-processor shared resource 144 and restarts the process. Along with this, the priority of the thread 162 is changed to “H”.

Thereafter, in the CPU 110, the thread 122 operates with the priority “L”.
In the CPU 150, the thread 162 obtains the inter-processor shared resource 142 (time t7), releases the inter-processor shared resource 142 (time t8), and releases the inter-processor shared resource 144 (time t9). Return to.

  As described above, in the real-time system 100 according to the present embodiment, the low-priority thread is executed by another processor core even during execution of the high-priority thread between time t2 and time t3 and after time t6. it can. Further, the occurrence of a deadlock can be avoided even when there is a shared resource between the processors.

  The present invention has been described above based on the embodiment. The embodiment is an exemplification, and various modifications, increases / decreases, and combinations may be made to the above-described embodiments without departing from the gist of the present invention. It will be understood by those skilled in the art that modifications in which these changes, increases / decreases, and combinations are also within the scope of the present invention.

  The real-time system 100 is an example in which the technique of the present invention is applied to a distributed multiprocessor system, but the scheduling technique of the present invention can also be applied to a non-distributed multiprocessor system.

  In the real-time system 100, the inter-processor shared resource acquisition information 210 is stored in the shared memory 200. The inter-processor shared resource acquisition information 210 may be held in any manner as long as any CPU can access the inter-processor shared resource acquisition information 210. For example, the inter-processor shared resource acquisition information 210 can be held while being updated as a library.

It is a figure which shows the real-time system concerning embodiment of this invention. It is a figure which shows the example of the shared resource acquisition information between processors memorize | stored in the shared memory in the real-time system shown in FIG. It is a flowchart which shows a process when the scheduling part in the real-time system shown in FIG. 1 makes an acquisition request with respect to a shared resource. It is a figure which shows the operation example in the real-time system shown in FIG. It is a schematic diagram of exclusive control performed when a shared resource is operated by a thread. It is a figure for demonstrating a binary semaphore system. It is a figure for demonstrating the deadlock problem which arises with a binary semaphore system. It is a figure for demonstrating a priority sealing system. It is a figure for demonstrating the deadlock which arises when a priority ceiling system is applied to the exclusive processing mechanism of a multiprocessor system.

Explanation of symbols

100 Real-time system 110 CPU
112 processor core 114 scheduling unit 122-128 thread 132-134 shared resource in processor 142-144 shared resource between processors 150 CPU
152 Processor Core 154 Scheduling Unit 162 to 168 Thread 172 to 174 Shared Resource in Processor 182 to 184 Shared Resource between Processors 190 Bus 200 Shared Memory 210 Shared Resource Acquisition Information between Processors

Claims (11)

In a multiprocessor system with shared resources that can be shared by multiple threads,
Perform exclusive control of the shared resource by priority sealing method,
Among the shared resources, the priority ceiling value of the inter-processor shared resource for a thread that has requested acquisition of the inter-processor shared resource that can be shared by a plurality of processor cores is other than the processor core on which the thread operates. A scheduling method characterized by causing a thread to acquire the inter-processor shared resource on condition that the priority ceiling value of any inter-processor shared resource being exclusively controlled by the thread in the processor core is larger. Each thread operates only on one processor core defined for the thread among the plurality of processor cores,
Scheduling between threads operating on the same processor core as the thread for threads that are not requesting acquisition of shared resources between processors that are under exclusive control by threads in a processor core other than the processor core on which they operate The scheduling method according to claim 1, wherein: Storing inter-processor shared resource acquisition information that associates the ceiling value of the inter-processor shared resource under exclusive control with the identifier of the processor core on which the thread that acquired the inter-processor shared resource operates;
3. The thread that has requested acquisition of any of the inter-processor shared resources determines whether to acquire the inter-processor shared resources based on the inter-processor shared resource acquisition information. Scheduling method according to claim 1. A scheduling device in a multiprocessor system having a shared resource that can be shared by a plurality of threads,
Perform exclusive control of the shared resource by priority sealing method,
Among the shared resources, the priority ceiling value of the inter-processor shared resource for a thread that has requested acquisition of the inter-processor shared resource that can be shared by a plurality of processor cores is other than the processor core on which the thread operates. A scheduling apparatus characterized by causing a thread to acquire the inter-processor shared resource on condition that the priority ceiling value of any inter-processor shared resource being exclusively controlled by a thread in the processor core is larger. Each thread operates only on one processor core defined for the thread among the plurality of processor cores,
Scheduling between threads operating on the same processor core as the thread for threads that are not requesting acquisition of shared resources between processors that are under exclusive control by threads in a processor core other than the processor core on which they operate The scheduling apparatus according to claim 4, wherein:   The scheduling apparatus according to claim 5, wherein the scheduling apparatus is provided for each processor core and performs scheduling of a thread that operates in the processor core in which the processor core is provided.   Stored in the storage device that stores the inter-processor shared resource acquisition information in which the ceiling value of the inter-processor shared resource under exclusive control is associated with the identifier of the processor core on which the thread that acquired the inter-processor shared resource operates. 7. The method according to claim 4, wherein it is determined based on the inter-processor shared resource acquisition information whether a thread that has requested acquisition of any inter-processor shared resource is to acquire the inter-processor shared resource. The scheduling apparatus according to any one of claims. Multiple processor cores,
A shared resource that can be shared by the plurality of threads;
Perform exclusive control of the shared resource by priority sealing method,
Among the shared resources, the priority ceiling value of the inter-processor shared resource for a thread that has requested acquisition of the inter-processor shared resource that can be shared by a plurality of processor cores is other than the processor core on which the thread operates. And a scheduling device that causes the thread to acquire the inter-processor shared resource on condition that the priority ceiling value of any inter-processor shared resource that is under exclusive control by the thread in the processor core is larger. Processor system. Each thread operates only on one processor core defined for the thread among the plurality of processor cores,
The scheduling apparatus is configured such that threads that operate on the same processor core as a thread that does not request acquisition of an inter-processor shared resource that is under exclusive control by a thread in a processor core other than the processor core on which the scheduling apparatus operates. The multiprocessor system according to claim 8, wherein scheduling is performed between them.   10. The multiprocessor system according to claim 9, wherein the scheduling device is provided for each processor core, and performs scheduling of threads operating in the processor core in which the scheduling device is provided. A storage device storing inter-processor shared resource acquisition information that associates the ceiling value of the inter-processor shared resource under exclusive control with the identifier of the processor core on which the thread that acquired the inter-processor shared resource operates;
The scheduling apparatus determines whether to acquire the inter-processor shared resource based on the inter-processor shared resource acquisition information stored in the storage device for a thread that has requested acquisition of the inter-processor shared resource. The multiprocessor system according to any one of claims 8 to 10, wherein

Images