JP4984153B2 - Block avoidance method in real-time task - Google Patents

Description

  The present invention relates to an operating system capable of supporting a symmetric multiprocessor (SMP), and more particularly to a block avoidance method for a real-time task when such an operating system is operated by a single processor.

  Embedded devices built into computers often require real-time processing. On the other hand, the advancement of embedded devices is required, the built-in computers are becoming larger, and the software that operates on them is becoming more complex. Therefore, the embedded operating system requires general functions such as a file system, a network, graphics, and a user interface in addition to the real-time processing function.

  Therefore, as a method for developing an operating system having both a real-time processing function and a general-purpose function, a method of adding a real-time processing function to a general-purpose operating system such as UNIX (registered trademark) or Windows (registered trademark) is used. .

  Linux (Linux), which is a type of UNIX, is highly convenient because it has many software components such as applications, libraries, and device drivers. Also, most of them are open source and can be modified if they do not meet the specifications.

  The Linux kernel does not inherently have real-time processing capabilities. The inventor of the present application has attempted to add a real-time processing function to Linux. The Linux operating system consists of a kernel and applications. The kernel consists of absolutely necessary core parts and removable optional parts. The core part has a task scheduling function, a system call for interfacing with an application, and the like. The optional part has a device driver, a file system, and the like. By changing the core part of the Linux kernel for real-time processing, a Linux operating system having real-time processing functions, that is, real-time Linux is obtained.

  In 1998, the inventors of the present invention developed ART-Linux 2.0, which is a real-time Linux compatible with Linux kernel 2.0 for Intel (registered trademark) x86 architecture. The inventors of the present invention developed ART-Linux 2.2 corresponding to the Linux kernel 2.2 in 2000, and developed ART-Linux 2.4 corresponding to the Linux kernel 2.4 in 2004. ART-Linux is the name of real-time Linux developed by the present inventor.

In general, a real-time operating system generally has the following functions and performance.
(1) Task scheduling based on fixed priority (2) Preemptive kernel (3) Sufficiently low interrupt latency
The real-time processing function in ART-Linux 2.4 will be described.

(1) Replacement of spin lock by mutex lock In order to reduce the maximum interrupt latency, it is necessary to shorten the longest preemption prohibition period. In the Linux kernel, it is difficult to specify the longest preemption prohibition period because critical sections that prohibit preemption (parts that fail when multiple processes are executed at the same time) are unevenly distributed in all source codes. In order to shorten the maximum preemption prohibition period, ART-Linux 2.4 replaced the spin lock, which performs exclusive control with the Linux kernel, with a mutex lock with multi-level priority inheritance (referred to as real-time lock). As a result, it is possible to preempt all the preemption prohibition periods ubiquitous in the Linux kernel. The maximum interrupt latency is determined by the longest preempt prohibition value that is unevenly distributed only during processing of the task scheduler specific to ART-Linux 2.4 or real-time lock processing. Therefore, the maximum interrupt latency can be guaranteed regardless of the function of the Linux kernel.

(2) Multi-level priority inheritance function When there is a dependency relationship between tasks in real-time processing, priority inversion occurs. As described above, the task switches with the mutex lock locked, and another task is blocked by this mutex lock, resulting in a priority inversion. Therefore, as described above, a multi-level priority inheritance function has been added. Also, a task that locks a mutex lock may be blocked by another mutex lock. Therefore, we implemented a function that inherits priority in multiple stages.

(3) Interrupt handler task If the interrupt handler is prioritized over the real-time task, the start of execution of the real-time task is delayed until the execution time of the interrupt handler ends, so the interrupt latency increases. On the other hand, when priority is given to a real-time task over an interrupt handler, priority inversion occurs when a certain real-time task waits for interrupt handler processing.

  Therefore, it is necessary to assign a priority to the interrupt handler and to set a high priority for the interrupt handler having a dependency relationship with the real-time task. ART-Linux 2.4 assigns priorities by executing interrupt handlers on real-time processing tasks. In addition, since the priority inheritance function of the real time lock automatically assigns the same priority as the dependent real time task, it is not necessary for the user application to set the priority of the interrupt handler.

(4) Not compatible with symmetric multiprocessor (SMP) The most basic functions in SMP support of the Linux kernel include a task scheduler and a spin lock that performs exclusive control. ART-Linux 2.4 has its own scheduler for real-time tasks, replacing spinlocks with realtime locks. However, these do not support SMP. For this reason, only one processor operates even when operated on SMP hardware including a multi-core processor.

  When an operating system capable of supporting a symmetric multiprocessor (SMP) is operated by a single processor, a real-time task may be exclusively controlled (blocked) by a mutex lock (real-time lock). When real-time tasks are blocked by mutex locks, real-time processing capabilities are degraded.

  It is an object of the present invention to prevent a real-time task from being blocked by a mutex lock and degrading a real-time processing function when a real-time operating system capable of supporting a symmetric multiprocessor (SMP) is operated by a single processor. It is to provide technology to do.

  According to the present invention, by passing the processing of the real-time task to another non-real-time task, the real-time task is prevented from being exclusively controlled (blocked) by the mutex lock. The process handed over to the non-real-time task is a process with a relatively low priority, and needs to be designated in advance by the user. Thus, processing with a relatively high priority is performed by a real-time task, and processing with a relatively low priority is performed by a non-real-time task.

  According to the present invention, since the real-time task is prevented from being blocked by the mutex lock, it is possible to prevent the real-time processing function from being deteriorated.

  In the process of developing a real-time linux kernel, the inventors of the present application can solve the problem of making the Linux kernel compatible with a symmetric multiprocessor (SMP) and stabilizing the real-time linux kernel by the same method. I found. Therefore, in the SMP-compatible Linux kernel, the processor is replaced with a task. Thus, the SMP-compatible Linux kernel can be used as a real-time Linux kernel in a single processor system. In the following, a case will be described in which an SMP-compatible Linux kernel is operated as a real-time Linux kernel in a single processor system.

  The inventor of the present application has developed ART-Linux 2.6 corresponding to Linux kernel 2.6. ART-Linux2.6 introduced "exclusive control based on virtual processor number" and "blocking real-time task block by queue". The present invention corresponds to “blocking real-time task block by queue”.

  In the following, a case will be described in which an SMP-compatible Linux kernel is operated as a real-time Linux kernel in a single processor system. However, the Linux kernel is described as an example, and the present invention is not limited to the Linux kernel. The present invention may be any operating system that supports SMP.

  A real-time task in ART-Linux 2.4 developed by the inventors of the present invention will be described with reference to FIG. In the SMP-compatible Linux kernel, a critical section that accesses shared data between tasks is controlled exclusively by spin lock. ART-Linux 2.4 uses mutex locks as an alternative to spinlocks as described above. That is, in ART-Linux 2.4, tasks are exclusively controlled by mutex locks.

  FIG. 1 shows only main parts in a computer system including a single processor 10. In addition to the single processor 10, this computer system includes a hard disk storing a real-time Linux kernel, a memory used when operating the hard disk, and the like, which are omitted here.

  As shown, a real-time Linux kernel is run on a single processor system. For example, when the real-time task 11 is accessing the shared data 15 between tasks, the other tasks 12 are exclusively controlled by the mutex lock 14. In other words, during execution of the real-time task 11, the other tasks 12 are exclusively controlled (blocked) by the mutex lock 14 and cannot access the area of the shared data 15 that is used by the real-time task 11. Further, the interrupt handler 13 is similarly exclusively controlled (blocked) by the mutex lock 14. The mutex lock is generally an exclusive control between different tasks, and only one task is allowed to enter the critical section at the same time. A mutex lock can only be unlocked by a locked task.

  Execution of the task 12 and the interrupt handler 13 that are exclusively controlled (blocked) by the mutex lock 14 is interrupted and enters a sleep state. Thereafter, when the real-time task 11 releases the mutex lock, the execution of either the task 12 or the interrupt handler 13 is resumed and the execution state is restored.

  The concept of the present invention will be described with reference to FIG. Of the real-time Linux kernel, the real-time task 21 having a relatively high priority includes a process 23 that is relatively unimportant. This process 23 is likely to be exclusively controlled (blocked) by the mutex lock. Such processing 23 is transferred from the real-time task 21 to the non-real-time task 22. Thereby, the real-time task 21 is executed without being controlled exclusively by the mutex lock. On the other hand, in the non-real-time task 22, there is a possibility that the process 23 is exclusively controlled by the mutex lock. However, even if the process 23 is exclusively controlled by the mutex lock, the real-time performance of the real-time task 21 does not deteriorate. In the non-real time task 22, for example, when the real time task 21 is finished, the process 23 is executed.

  An exclusive control avoidance method according to the present invention will be described with reference to FIGS. FIG. 3 shows a case where processing in a real-time task having a relatively high priority is executed. It is assumed that this process may be exclusively controlled by a mutex lock. First, in step S101, this task performs mutex lock processing. If another task has not locked the mutex lock before the mutex lock processing, the process proceeds to the next step S102. If another task has locked this mutex lock, this task goes to sleep and switches to another task. If another task releases the lock, this task is in an execution state and proceeds to the next step S102. In step S102, process f is executed. In this process f, data 31 is used. After the process f is completed, the mutex lock process is released in step S103. Thus, the process f may be exclusively controlled by locking the mutex lock by another task in step S101. Therefore, the procedure 0 in FIG. 3 is broken down into two procedures 1 and 2 shown in FIG.

  As shown in FIG. 4, the procedure 1 is a process in the real-time task 21 having a high priority. In the procedure 1, first, in step S201, the interruption is prohibited. The interruption prohibition is an exclusive control that does not call the scheduler, and may be a spin lock or the like. In step S202, the process f is delivered. In the delivery of the process f, for example, the process f and data are put in the queue 32. The queue 32 means a memory area. When the delivery of the process f is completed, the interrupt prohibition is canceled in step S203. During the interrupt prohibition period, the process does not branch to the interrupt process, so that no other task or interrupt handler is executed, and no other task or interrupt handler accesses the shared data.

  Procedure 2 is a process of the non-real time task 22 having a low priority. First, in step S301, interruption is prohibited. In step S302, process f is received. That is, the process f and data are extracted from the queue 32. When the reception of the process f is completed, the interrupt prohibition is canceled in step S303. Steps S304 to S306 are the same as procedure 0. That is, in step S304, mutex lock processing is performed. Next, in step S305, process f is executed. In this process f, data 31 is used. After the process f is completed, the mutex lock is unlocked in step S306.

  As described above, before execution of the process f, in step S304, the non-real-time task 22 may be interrupted by the lock of the mutex lock by another task. However, since the non-real-time task 22 is less important, there is no inconvenience even if processing is interrupted. Even if the non-real time task 22 is blocked by the mutex lock before the execution of the process f, the real time performance of the real time task is not deteriorated.

  As described above, in the present invention, a process with relatively low importance among real time task processes, that is, a process that is easily blocked by a mutex lock is transferred to a non-real time task and executed there. Thereby, it is avoided that the real-time task is blocked by the mutex lock, and the execution of the real-time task can be made efficient.

  Therefore, it is necessary for the user to select a process with a relatively low importance among the processes of the real-time task in advance. For example, the user may search for a code for non-real-time processing. The following two examples are given as such relatively low importance processing.

(1) Task termination processing Task termination processing is one of the processes that are likely to cause problems in an SMP-compatible Linux kernel. When the task ends, it notifies the parent task and executes the scheduler to switch to another task. The parent task releases the memory area of the task structure of the finished task. The memory release processing of the parent task needs to be executed after the switch of the finished task. However, if it is executed by another processor, the order is not guaranteed. That is the problem.

  In Linux kernel 2.6, if the end process switch is slower than the memory release by the parent process, the parent process is not processed, and the next task that is switched performs the process of releasing the memory to avoid the problem. Yes. If this process is performed in ART-Linux 2.6, the next task may be a real-time task. Therefore, there is a possibility that the real time lock (mutex lock) necessary for the memory release processing is blocked. Therefore, according to the present invention, the reduction in real-time processing performance is prevented by transferring the memory release processing to the next non-real-time task to be executed.

(2) Transfer processing between run and queue
ART-Linux2.6 introduced the O (1) scheduler. There are multiple run queues depending on the priority of the task, and a bitmap variable in which the bit corresponding to the run queue including the executable task is set to 1, from which the search for the highest priority task is performed. The scheduler is executed with the processing amount of (1). In ART-Linux 2.6, the Linux scheduler does not manage real-time tasks. Real-time tasks should be removed from the Linux run queue, but not in ART-Linux 2.4. However, since it is not consistent with the O (1) scheduler, the real-time task is deleted from the Linux run queue.

  Then, when a real-time task returns to a non-real-time task, it may have to be reinserted into the Linux run queue. That is, the process may be performed by a real-time task. The run queue is shared data and requires exclusive control by a corresponding real-time lock (mutex lock) at the time of access. Therefore, according to the present invention, the run queue is transferred to the next non-real time task to be executed, thereby preventing the real time processing performance from being deteriorated.

  The example of the present invention has been described above, but the present invention is not limited to the above-described example, and various modifications can be easily made by those skilled in the art within the scope of the invention described in the claims. It will be understood.

  For example, the case where an SMP-compatible Linux kernel is operated on a single processor system has been described above. However, the Linux kernel is described as an example, and the present invention is not limited to the Linux kernel. The present invention may be any operating system that supports SMP.

It is explanatory drawing explaining the exclusive control (block) with respect to the real-time task in a real-time operating system. FIG. 5 is a conceptual diagram illustrating a block avoidance method for a real-time task according to the present invention. It is a figure explaining the process of the block avoidance method with respect to the real-time task by this invention. It is a figure explaining the process of the block avoidance method with respect to the real-time task by this invention

Explanation of symbols

10 ... CPU, 11, 12 ... task, 13 ... interrupt handler, 14 ... mutek lock, 15 ... shared data, 21, 22 ... task, 23 ... processing, 31 ... data, 32 ... queue

Claims (10)

Of real-time tasks and non-real-time kernel task operating system have you, real-time task is blocked from other tasks by the mutex lock when the operating system capable corresponds to symmetric multiprocessor operating by a single processor In a way to avoid that,
And that by the single processor starts executing real-time tasks,
Executing an interrupt prohibition process by the single processor ;
Taking out a predetermined process previously designated by the user from the real-time task by the single processor and adding it to another non-real-time task;
Executing a process of canceling the interrupt inhibition by the single processor ;
Executing the remaining processing by extracting the predetermined processing from the real-time task by the single processor ;
Only including,
A block avoidance method for a real-time task , wherein the predetermined process is determined by a user as being more likely to be blocked than other processes due to a mutex lock . The block avoidance method for a real-time task according to claim 1,
Initiating execution of the other non-real-time task by the single processor;
Performing the predetermined processing added to the other non-real-time task by the single processor;
Blocking the other task with a mutex lock during execution of the predetermined process added to the other non-real time task by the single processor;
A block avoidance method for real-time tasks. The block avoidance method for a real-time task according to claim 1,
The block avoidance method for a real-time task, wherein extracting the predetermined process from the real-time task is a process of storing the predetermined process and data necessary for the predetermined process in a predetermined memory. The block avoidance method for a real-time task according to claim 1 ,
The block avoidance method for a real-time task, wherein adding the predetermined process to another non-real-time task is a process of reading the predetermined process and data necessary for the predetermined process from a predetermined memory .   2. The block avoidance method for a real time task according to claim 1, wherein the operating system is operated by a computer system having a single processor.   A computer-readable program for causing a block avoidance method for a real-time task according to any one of claims 1 to 5 to be executed on a computer having a single processor. In a real-time information processing apparatus having an operating system capable of supporting a symmetric multiprocessor, a single processor that operates the operating system, and a memory,
Among the real-time task and non- real-time task of the kernel of the operating system, the single processor starts execution of the real-time task , executes the interrupt prohibition process, and from the real-time task, a predetermined user designated in advance Remove the process in addition to other non-real-time tasks, performs a process of canceling the interrupt disabled, it performs the real time remaining processing taken out the predetermined processing from the task,
The real-time information processing apparatus according to claim 1, wherein the predetermined process is determined by the user as being more likely to be blocked than other processes due to a mutex lock . The real-time information processing apparatus according to claim 7,
The execution of the other non-real time task is started by the single processor, and the predetermined process added to the other non-real time task is executed.
A real-time information processing apparatus that blocks another task by a mutex lock during execution of the predetermined process added to the other non-real-time task. The real-time information processing apparatus according to claim 7,
Extracting the predetermined process from the real-time task is a process for storing the predetermined process and data necessary for the predetermined process in the memory. The real-time information processing apparatus according to claim 7 ,
Adding the predetermined process to another non-real-time task is a process for reading out the predetermined process and data necessary for the predetermined process from the memory.

Images