DE102016214584A1 - Method and device for time control in a system - Google Patents

Abstract

Method (10) for scheduling in a system, characterized by the following features: a process in the system (20) stores a priority request (11) in the random access memory, - if an interruption of the process is requested, the system (20) reads the priority request (11) from the random access memory (12) and dependent (13) from the priority request (11) handles (14) or suppresses (15) the system (20) case by case (Y, N) the interruption.

Description

The present invention relates to a method for timing control in a system. The present invention also relates to a corresponding device, a corresponding computer program and a corresponding storage medium.

State of the art

In operating system theory, the allocation of processing time to various processes - also called tasks in some operating systems - is referred to as scheduling. One challenge of timing control is that the resources required for individual processes are not known prior to their execution. In general, therefore, it is not possible to predetermine an optimal timing in advance, but the timing control has to react to changing requirements at runtime. Different allocation strategies can be used. One prior art technique often used for scheduling is so-called priority scheduling, which prioritizes each process and each executes the highest priority executable process in the system.

DE 19744230 A (ROBERT BOSCH GMBH) 08.04.1999 discloses a control device for a system, in particular a motor vehicle, a motor or a gearbox having a plurality of activatable modules, wherein activated modules generate information by observing states of the system, wherein a scheduler for the Activation of the modules is provided, wherein the scheduler for the activation takes into account a priority assigned to the modules, wherein a priority manager is provided which changes the priority of the modules, and wherein the priority manager the priority of modules in response to an activation message is displayed with that the module in question has been activated, changed.

Disclosure of the invention

The invention provides a method for scheduling in a system, a corresponding device, a corresponding computer program and a machine-readable storage medium according to the independent claims.

A merit of this approach is the improved efficiency of the user code in prioritizing operating systems and hypervisors in the event that the operating system or hypervisor is to execute the user code in a nonprivileged mode in which the code must request the operating system or hypervisor and that priority switching occurs very frequently with respect to certain operations such as interrupt handling and interrupt handling.

The proposed approach is based on the recognition that an embedded operating system or a corresponding hypervisor often makes a distinction between two modes: a privileged mode and a nonprivileged mode. In nonprivileged mode, code is typically forbidden to change the priority of the processor. If such a user code wishes to change the priority, then it makes a request to the operating system or hypervisor, which then performs the change before the return. This mechanism according to the scheme "request-priority-change-return" often binds significantly more resources compared to a mere change of priorities. However, it is typically the only available mechanism and thus must be used.

The priority switching mechanism is typically used to implement critical sections in user code. If data (or a particular device) needs to be protected from concurrent access, the priority is raised to prevent other portions of the code from executing, the data or device is accessed, and then priority is restored. So every critical section needs to change the priority at least twice.

Simultaneous accesses are usually based on interrupt routines (interrupt service routine, ISR). Increasing the priority of the processor limits the disruptions that can occur in the critical sections.

In some applications, critical sections rarely occur, and thus the cost of the described request-priority-change-return mechanism can be accepted. However, other applications include critical sections that are executed many thousands of times per second - much more often than the interruptions they protect against. In these cases, if the code is migrated from a privileged system to a nonprivileged system (for security, for example), the additional overhead can become unacceptable because a significant portion of the available processor capacity is needed.

A method according to the invention therefore provides a mechanism that allows nonprivileged code to quickly change the priority in systems where the number of critical ones is high Sections (and thus the number of priority changes) is much higher than the number of interrupts.

The measures listed in the dependent claims advantageous refinements and improvements of the independent claim basic idea are possible. Thus, it can be provided that when suppressing an interruption, the system sets a status indicator (flag) in the random access memory (RAM) of the system. As soon as the process deletes the priority request, it executes a query of the status indicator in this embodiment. In the ordinary case, since the entry into and exit from the critical section will dominate the occurrence of interrupts, the code involved will be very fast and will only execute the following runtime instructions: setting a variable in RAM upon entry and resetting the variables in RAM from the negative check of another Boolean variable on exit.

According to a further aspect, in the event that the status indicator is set at the query, it may be provided that the process calls the system and the latter handles the suppressed interrupt and deletes the status indicator from random access memory. Thus, in the unusual case that a break occurs in a critical section, additional overhead in the interrupt routine code and the critical section exit code arises because the Boolean variable check is positive and a trap by the operating system or hypervisor caused a certain system-internal computational effort. However, since this case occurs very rarely, said additional expenses should be acceptable.

Brief description of the drawings

Embodiments of the invention are illustrated in the drawings and explained in more detail in the following description. It shows:

1 the flowchart of a method according to a first embodiment.

2 schematically a control device according to a second embodiment.

Embodiments of the invention

1 illustrates, by way of a greatly simplified illustration, the basic functional features of an embodiment of the invention. The following description also illuminates separately the processes on the one hand the increase of the priority and on the other hand the lowering of the priority.

Regarding the memory configuration of the implementation, it is assumed that the privileged code (of the operating system or hypervisor) and any nonprivileged code share a RAM that is readable and writable for all processes. At least two variables are managed in this RAM: the priority request ( 11 ) and a status indicator indicating a suppressed interrupt.

To increase the priority, the nonprivileged code writes the new priority request ( 11 ) at a predefined location in the shared memory. No change in the priority of the processor takes place in the course of this write command. Rather, the RAM stores the claimed priority.

Should an interrupt occur while the claimed priority is increased, then the program that interfaces with the interrupt routine (wrapper) and thus executes before the interrupt routine, performs the following steps: It verifies (step 12 ) the priority request ( 11 ) in the shared memory, indicating whether the device in question can be allowed to interrupt the user code (ie whether its priority is higher than the data stored in RAM). If (branching 13 ) the interruption is allowed (branch Y), it is treated directly (step 14 ).

On the other hand, if the interruption is not allowed (branch N), then the priority of the processor according to the priority request ( 11 ), the status indicator in shared memory is set, and the source of the interrupt request is stored in RAM for later use.

A reduction in the interrupt priority occurs in two steps: the new priority request ( 11 ) is stored as the value of the shared RAM variable, the status indicator in the shared RAM is checked, and if the status indicator is set, the operating system or hypervisor is called, typically with a so-called trap statement.

Upon this trap instruction, the operating system or hypervisor that had previously noted which interrupt has been suppressed clears the pending interrupt indication, forwards the stored interrupt request to the interrupt routine, and returns to the calling process.

• 1. In einem Betriebssystem etwa mögen die Aufgaben und Unterbrechungsroutinen Zugriff auf den gesamten Prioritätsraum haben. Ein typisches kraftfahrzeugtechnisches Betriebssystem offener Architektur (automotive open system architecture, AUTOSAR) – obgleich das vorliegende Konzept nicht auf ein solches beschränkt ist – ermöglicht ausgewählten Funktionseinheiten den Betrieb in einem nichtprivilegierten Modus, in welchem der Eintritt in kritische Abschnitte aufwändig und ein Zugriff auf das gesamte Spektrum der Prioritäten erforderlich ist.
• 2. In einem Hypervisor ist das Spektrum der Prioritäten, auf welche eine (ein Gast-Betriebssystem oder eine Anwendung ausführende) VM Zugriff hat, typischerweise auf eine Teilmenge des durch den Prozessor zur Verfügung gestellten Spektrums begrenzt. a. In dem Fall, dass nur Aktivieren und Deaktivieren unterstützt werden, obliegt es dem Hypervisor, die Prioritätsanforderung (11) in einen zum Unterdrücken von Unterbrechungen geeigneten Wert aus dem zusammenhängenden Bereich umzusetzen. b. In dem Fall, dass ein zusammenhängender Wertebereich unmittelbar zur Verfügung steht, prüft der Hypervisor die Gültigkeit der Prioritätsanforderung (11) erst, wenn die Ausführung an den Hypervisor übergeben wird.

Embodiments of the described system may be made for a variety of circumstances. So likes the "priority room" of a particular virtual machine (VM), task or interruption routine consist of two discrete values (interrupts enabled or disabled) which, as it were, mask a contiguous range of values, or directly from a contiguous range of values (for example that of integers from 0 to 15 ). This concept works equally well in systems with two or more values included in the priority space.

• 1. In an operating system, for example, the tasks and interrupt routines may have access to the entire priority space. A typical automotive open system architecture (AUTOSAR) - although not limited to the present concept - allows selected functional units to operate in a nonprivileged mode in which entry into critical sections is laborious and access to the entire Range of priorities is required.
• 2. In a hypervisor, the range of priorities to which a VM (executing a guest operating system or application) has access is typically limited to a subset of the spectrum provided by the processor. a. In the case that only enable and disable are supported, it is up to the hypervisor to fulfill the priority request ( 11 ) into a value suitable for suppressing interruptions from the contiguous area. b. In the event that a contiguous range of values is immediately available, the hypervisor checks the validity of the priority request ( 11 ) only when the execution is passed to the hypervisor.

This method ( 10 ) can be used, for example, in software or hardware or in a mixed form of software and hardware, for example in a control unit ( 20 ), as the schematic representation of 2 clarified.

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• DE19744230A [0003]

Claims (10)

Procedure ( 10 ) for timing control in a system ( 20 ) with a random access memory, characterized by the following features: a process in the system ( 20 ) issues a priority request ( 11 ) in the random access memory, - If an interruption of the process is requested, the system reads ( 20 ) the priority request ( 11 ) from random access memory ( 12 ) and - dependent ( 13 ) from the priority request ( 11 ) ( 14 ) or suppressed ( 15 ) the system ( 20 ) occasionally (Y, N) the interruption. Procedure ( 10 ) according to claim 1, characterized by the following features: - in suppressing ( 15 ) the interruption sets the system ( 20 ) a status indicator in the random access memory and - the process deletes the priority request ( 11 ), the process executes a query of the status indicator. Procedure ( 10 ) according to claim 2, characterized by the following features: if the status indicator is set during the query, the process calls the system ( 20 ), - the system ( 20 ) deals with the suppressed interruption and - preferably through the system ( 20 ) clears the status indicator from random access memory. Procedure ( 10 ) according to one of claims 1 to 3, characterized by the following features: - the system ( 20 ) is an operating system and - the priority requirement ( 11 ) comprises a value from a given set of values. Procedure ( 10 ) according to one of claims 1 to 3, characterized by the following features: - the system ( 20 ) is a hypervisor and - the process runs in a virtual machine under the hypervisor. Procedure ( 10 ) according to claim 5, characterized by the following features: - the priority request ( 11 ) includes a lock indicator and - is the lock indicator when reading ( 12 ) of the priority request ( 11 ), the hypervisor converts the lock indicator into a value from a given set of values. Procedure ( 10 ) according to claim 5, characterized by the following features: - the priority request ( 11 ) includes a value from a predetermined, preferably contiguous range of values and - the hypervisor validates the priority request ( 11 ) when reading ( 12 ) based on a subset of the set of values associated with the virtual machine. Computer program, which is set up the procedure ( 10 ) according to one of claims 1 to 7. Machine-readable storage medium on which the computer program according to claim 8 is stored. Contraption ( 20 ), which is set up, the procedure ( 10 ) according to one of claims 1 to 7.

Images