JPH01195542A - Multi-programming processor - Google Patents

Abstract

PURPOSE:To decrease the interruption inhibiting areas and to improve the interruption response by permitting or inhibiting the operation of data based on the storage state. CONSTITUTION:When a processor containing three exclusive instructions carries out a deleting instruction, the processor decides a control flag included in an OS data control part 11 corresponding to a relevant queue. The normal processing of an instruction V is carried out only in case no access conflict occurs with a semaphore at occurrence of an instruction. In a successive process of an instruction P, a dispatch instruction is carried out after a task is deleted out of a ready queue to complete said successive process. In such a way of processing, an operating system can be described without inhibiting the interruption during execution of a system call instruction P and the instruction V.

Description

DETAILED DESCRIPTION OF THE INVENTION Field of Industrial Application The present invention relates to an information processing device that realizes multiprogramming processing that executes multiple tasks in parallel in response to events that occur asynchronously inside or outside a computer. Regarding.

Conventional technology Conventionally, in multiprogramming systems, a program is divided into multiple tasks and each task is executed in a time-sharing manner, giving the appearance that each task is being executed in parallel. is taken.

The operating system manages the execution status and synchronization relationship of each task, and the operating system is usually realized by a combination of instructions. In order to manage each task, the operating system operates on data structures allocated to each task.
Manage task status, task execution environment, etc.

Furthermore, the operating system has a number of functions, and these functions can be utilized by issuing system calls from the program program to the operating system.

However, in a multiprogramming system, if multiple tasks issue the same system call at the same time, they will interfere with each other and cause a problem, so the operating system manages to prevent multiple tasks from issuing the same system call at the same time. are doing.

FIG. 6 shows an example of mutual exclusion when using system calls in a multiprogramming system.

In this example, an example of mutual exclusion when two tasks, task 1 and task 20, use a common Ilo will be described.

Normally, a flag called a semaphore is used for mutual exclusion, and system calls for operating this semaphore include P and V instructions.

First, between task 1 and task 2, the one that transitions to the execution state sooner issues system call P. now,
Assume that task 1 obtains execution rights first. In the processing of system call P, the pit (hereinafter referred to as semaphore pit) indicating whether the semaphore is set or reset is determined, and if the semaphore is set, it is reset, and control immediately returns to the point in time when system call P was issued. , continue processing.

When task 1 is processing common I10, control is transferred to task 2 due to an interrupt, etc., and task 2 also issues a P command to the semaphore in order to process the same common I10.The semaphore pit is already in the reset state. Therefore, task 2 transitions to the wait state.

When task 1 completes its processing and issues a V command for the semaphore, task 2, which is in the wait state for that semaphore, is released from the wait state and can transition to the execution state. In other words, by issuing the V instruction by the preceding task 1, task 2 issues the above common I10 command for the first time.
It becomes possible to transition to processing.

The mechanism described above prevents conflicts when multiple tasks perform common processing.

FIG. 7 shows the processing of the operating system corresponding to the P command and the ■ command, and describes the general flow.

In the processing of the P instruction, the data area for the corresponding semaphore is calculated from the semaphore identifier specified by the operand of the P instruction, and the semaphore bits managed in the data area are determined.

If the semaphore bit is already in the cleared (reset) state, interrupts are disabled in step 1, the P command issuing task is registered in the semaphore waiting task queue, and the status of the issuing task is changed to the waiting state. Furthermore, the issued task is deleted from the executable task management block (hereinafter referred to as ready-to-do task), and the next task to be put into the execution state is selected.

(Hereinafter, this will be referred to as dispatch processing.) After that, interrupts are enabled at 8I.

If the semaphore bit is already set, just clearing the semaphore bit will immediately perform dispatch processing.

■In instruction processing, like the P instruction, the data area for the corresponding semaphore is calculated from the semaphore identifier specified by the operand of the V instruction, and the waiting task queue managed in that data area is determined. do.

If there is a task in the waiting task queue, use DI to disable interrupts, delete the waiting task from the waiting task queue, change the status of the task from waiting to executable, and register the task in the ready queue. , performs dispatch processing. After that, use El to enable interrupts.

If there is no waiting task in the waiting task queue, dispatch processing is performed immediately by simply setting the semaphore bit.

Although the details vary depending on how the operating system is designed, the flow described above is generally the basic method for implementing operation commands for semaphores.

Problems to be Solved by the Invention As mentioned above, when multiple tasks and operating systems run on the same processing device, care must be taken when accessing shared data so as not to destroy each other's execution environment. It is necessary to design the algorithm while paying for it.

For example, in the section in FIG. 7 where an interrupt would cause inconvenience, interrupts are not permitted to prevent multiple tasks from competing with each other regarding access to data managed by the operating system.

The problem that would occur if interrupts were enabled for all sections of the flow will be explained below with reference to FIG.

FIG. 8 shows that during the execution of task l, a P instruction is issued to a semaphore, and during the operating system processing corresponding to the P instruction, an interrupt from the interrupt system provided in the processing unit occurs, and the interrupt processing routine This shows a case where a V instruction for the same semaphore is issued in the program.

Assuming that an interrupt occurs at the INT position in Figure 7,
Since task 1 is in the state before the ready queue operation in the P instruction processing, interrupt processing is performed while task 1, which issued the P instruction, is still registered in both the semaphore task waiting queue and ready queue. Control will be transferred to the routine.

In this state, when a V instruction is issued from the interrupt processing routine, task 1 is deleted from the task waiting queue because there is already a "waiting task" state, and the task status of task l becomes executable and ready. Requeued. However, since task 1, which issued the above-mentioned P command, is still registered in the ready queue as being in an execution state, task 1 is registered twice in the ready queue.

, the interrupt handling routine returns control to task 1, assuming that the interrupt has ended normally if the processing of the V instruction described above is completed normally.

When control is returned to the first task 1 from the interrupt processing routine, processing continues from INT in FIG.

Task 1 continues the state it was in before the interrupt occurred and executes this process, so the task status of task 1 returns to the waiting state again, and the ready queue operation during the P instruction processing causes the task to be read from the ready queue. The registration of task l is deleted.

However, at this time, since task 1 has already been registered twice in the ready queue, it is expected that a malfunction will occur during the deletion process.

Depending on how you implement registration and deletion,
The point at which the problem becomes apparent depends on the point in time, but in any case, when achieving mutual exclusion when accessing the common I10 using the above combination of P and V instructions, 1 and 1. Setting the section to an interrupt-enabled state will lead to the above-mentioned malfunction.

In multiprogramming operating system processing, the above problem occurs not only with P instructions and ■ instructions, so it is common to disable interrupts in various places to protect processing from interrupts that occur asynchronously. .

- Yoshihashi, application programs that apply multiprogramming have many fields in which processing performance is a particular problem, and there are cases where responses to interrupts must be made in real time. Therefore, there is a need to design operating systems so that they can accept interrupts at any time.

However, as mentioned above, operating systems designed to realize multiprogramming have some parts that must protect their processing from interrupts due to their mechanism, which causes the problem of reduced responsiveness to interrupts. There was a point.

SUMMARY OF THE INVENTION Accordingly, an object of the present invention is to solve the problems of the prior art described above and to provide a multiprogramming processing device that exhibits high responsiveness to interrupts.

Means for Solving the Problems According to the present invention, a multiprogramming processing device that executes a plurality of tasks in parallel is provided with dedicated instructions for manipulating data related to each task managed by an operating system, and There is provided a multiprogramming processing device characterized by comprising means for storing information that the data has been manipulated, and determining means for permitting or disallowing the manipulation of the data based on the storage state.

The multiprogramming processing device of the present invention is an improvement over the conventional multiprogramming processing device that provides many interrupt-disabled sections in order to protect processing from interrupts, resulting in a decrease in responsiveness to interrupts.

The multiprogramming processing device of the present invention prevents interrupts from being disabled as much as possible during operating system processing by using dedicated instructions for manipulating data managed by the operating system and means for recording that the management data has been manipulated. , which has the original content of improving interrupt responsiveness.

In other words, in conventional processing devices, if an interrupt occurs while a task is being processed and the same Ilo that is being used by the previous task is accessed within the interrupt processing routine, multiple tasks will interfere and cause malfunctions. . Therefore, parts where interrupts were expected to cause the above malfunction were prevented by disabling interrupts.

In the processing device of the present invention, if a previous task accesses the same Ilo that is in use within the interrupt processing routine,
First, the state of the storage means that stores whether the Ilo is in use is checked, and if the Ilo is in use, the determining means disallows access.

Therefore, even if interrupts are not prohibited, multiple tasks will not interfere with each other.

Embodiments Embodiment 1 FIG. 1 is a block diagram of an example of a multiprogramming processing device of the present invention. The multiprogramming processing device of this embodiment has three instructions for the semaphore: "instruction to register task in waiting queue", "instruction to delete task from waiting queue", and "dispatch instruction" as dedicated instructions for multiprogramming processing. .

The multiprogramming processing device of the present invention shown in FIG. The ALU section is similar to the conventional combination unit with a register 5 that inputs and outputs data, an ALU 4 connected to the register 5 and a selector 13, and a temporary latch 12 that latches the output of the ALU 4 and outputs it to the data bus 2. is formed.

Also 1, at least 3 degrees of multiprogramming mentioned above.
The instruction queue 6 stores the operation code of a dedicated instruction, and outputs the operation code of a predetermined instruction to the entry decoder 7 in response to an operating system signal inputted manually via the data bus 2. Decode the operation code of the instruction,
The entry decoder 7, which generates the entry address to the microprogram memory 9, receives data such as the queue structure identifier of the task waiting queue or ready queue, the abort destination address, etc. when processing the 3 dedicated instructions for multiprogramming described above. The control section includes an operand buffer 8 to be stored and a selection signal generation section 10 that generates a selection signal to the OS data management section 11 based on the data in the operand buffer 8.

In this embodiment, all dedicated instructions are processed by microprograms.

In processing an instruction to register a task in a waiting queue, the operand buffer 8 uses as operands the identifier of the queue structure of the waiting queue set on the memory and the address of the abort destination in the case of abort.

The selection signal generation unit 10 generates a selection signal to the O3 (operating system) data management unit 11 from the identifier of the waiting queue stored in the operand buffer 8.

The OS data management unit 11 that receives the above selection signal holds flags corresponding to each data structure managed by the operating system, and the operating system executes the queue operation or aborts the queue operation depending on the state of the flag. do. That is, when this flag is in the reset state, it is operable, so after executing the task registration process in the waiting queue, the corresponding flag is set in the set state.

Furthermore, when the flag is set, the waiting queue cannot be operated, so the bus interface section 3 starts from the abort destination address stored in the operand buffer 8.
then jump to the abort address.

In the case of processing an instruction to delete a task from a waiting queue, as in the case of a registration instruction, the operand buffer 8 stores as an operand the identifier of the queue structure of the waiting queue set in memory and the address of the abort destination in the case of abort. Store.

The operating system determines the state of the OS data management unit 11, and if the flag corresponding to the wait queue specified by the operand of the operand buffer 8 is set, it aborts, and if it is reset, it deletes the task from the wait queue. , set the flag.

In the dispatch instruction, the address to the ready queue set on the memory is stored as an operand in the operand buffer 8, and based on this operand, the operating system selects a task to transition from the ready queue state to the next execution state. A dispatch process is performed to select the data, and the flags corresponding to each data in the OS data management unit 11 are reset.

FIG. 2 is an example of the processing of the operating system for the P and V instructions using the dedicated instructions on the processing device shown in FIG. 1, which is equipped with the above three dedicated instructions.

In the processing of the P instruction, in the processing of the task registration instruction to the waiting queue, before executing the registration process, a flag that holds information on whether the queue operation is possible is determined, and if the queue operation is possible, the registration process is executed. Execute, and if the operation is not possible, abort without executing the queue operation.

■ Waiting for command processing Even when processing a task deletion command from the key 21, as with the registration command, before executing the deletion processing, a flag that holds information on whether queue operation is possible or not is determined,
If the queue operation is possible, delete processing is executed; if the queue operation is not possible, the queue operation is not executed and is aborted.

In both the P instruction processing and the ■ instruction processing, the dispatch instruction selects the task to be next transitioned from the ready queue state to the execution state, and sets the flag to the queue operation enabled state.

On a processing device equipped with dedicated instructions as shown in Figure 1,
By designing the P and ■ instructions of the operating system using the algorithm shown in FIG. 2, the entire flow section can be enabled for interrupts.

Hereinafter, by instructing the multiprogramming processing device of this embodiment, as shown in the flow shown in FIG.
Consider the case where an interrupt occurs during instruction processing. It is assumed that an interrupt occurs at the INT position shown in FIG.

The Sunawachi operation system is processing the system call P instruction issued by task 1, executes the instruction to register task 1 in the waiting queue, and sets the corresponding flag in the OS data management unit. Also, the status of task 1 is set to the waiting state.

When an interrupt occurs, control is transferred to the interrupt handling routine, and a system call V instruction is issued in the interrupt handling routine. Execute a task deletion instruction from the queue.

In the device of this embodiment, when executing a deletion command, first the management flag in the OS data management unit corresponding to the queue is determined. Since it is already in the set state here, execution is aborted and jumps to the abort address.

Issuing a progera and branch tem call typically
When control is returned, information regarding the execution of system call processing is returned from the operating system as a condition code.

This condition code is generally notified to the program that issued the system call by being returned to a specific register.

Therefore, as described above, if a program issues a V instruction but its execution is aborted because it is processing a P instruction, a condition code indicating that the program has been aborted is returned.

When the processing within the routine does not end normally, the interrupt processing routine does not continue the subsequent processing, immediately executes the interrupt end code, and returns to the point at which the P instruction interrupt occurred. Therefore, in the above case, the V instruction issued during the interrupt processing is aborted, so the interrupt processing ends and immediately returns to the point at which the interrupt occurred.

In the processing device of this embodiment, normal processing of the (1) instruction is executed only when an interrupt occurs and no access conflict occurs regarding the semaphore.

In the continuation processing of the P command, a dispatch command is executed after performing a task deletion operation from the ready queue. The dispatch command resets the management via corresponding to the semaphore waiting queue in the OS data management section,
Finish the process.

By performing the above processing, system call P
It becomes possible to write an operating system without disabling interrupts in the middle of an instruction.

Embodiment 2 In multiprogramming processing, since each task operates independently, it is often necessary to send and receive data between tasks. The operating system supports functions for sending and receiving data, and the system call RBCBIVE-DATA.

This corresponds to the 5END-DATA command. In this embodiment, the processing device of the present invention is applied when transmitting and receiving data between tasks.

FIG. 3 shows an example of data transmission and reception between tasks. Task 3 is:
Data is received from other tasks by issuing the DATA command. If no data has been sent from another task when the system call is issued, that task transitions to a wait state.

Task 4 sends data to other tasks by issuing system call 5BND-DATA. At that time, if there is already a task waiting for a reception request, the task is released from the waiting state and the data is transmitted. If there are no waiting tasks, the transmission data is registered in the queue.

Figure 4 shows cis7A:1-ruRBcBIVB-D
An interrupt occurs during the execution of an ATA instruction, and in the interrupt processing routine, a transmission system call SBN low DATA is issued.
This shows the case where . The flow in this case is exactly the same as the flow shown in FIG. 8 when an interrupt occurs while the P instruction is being issued and the V instruction is issued during the interrupt processing routine.

The processing device of this embodiment also has a structure similar to that of FIG. 1 shown in Embodiment 1.
, "Delete task from waiting key 21 instruction" and "Dispatch instruction" as dedicated instructions for multiprogramming processing.

FIG. 5 shows the case (7) RECEIVE-DATA command and S
F! The N-row DATA instruction algorithm allows the entire flow section to be enabled for interrupts.

System f A: l-R11i During processing of the CBIVB-DATA command, if there is no received data, execute the task registration command to the waiting queue, register the task to the waiting queue, and register the corresponding bit in the OS data management section. Set state. Then, the status of task 3 is set to a waiting state.

When an interrupt occurs at the INT position in Figure 5, control is transferred to the interrupt handling routine, and a system call 5END-DATA instruction is issued in the interrupt handling routine.
In the processing of the 5END-DAT human command in FIG. 4, since there is a task waiting for a monitor reception request, a task deletion command from the waiting queue is executed. In the deletion order,
The management bit in the OS data management unit corresponding to the queue is determined. Since it is already in the set state here, execution is aborted and jumps to the abort address.

I issued the 5END-DATA command as above, but R
If execution is aborted because the ECBIVB-DATA instruction is being processed, a condition code indicating that it has been aborted is returned, the interrupt processing is not continued, the interrupt end code is immediately executed, and the RECBIV
The process returns to the point in time when the B-DATA instruction interrupt occurred. 5
Normal processing of the ENO-DATA instruction is executed if there is no access conflict regarding data transmission and reception when an interrupt occurs.

In the continuation of the system call RBCEIVB-DATA instruction, a dispatch instruction is executed after a task is deleted from the ready queue. The dispatch command resets the management bit corresponding to the waiting key 11 of the reception task in the OS data management section, and ends the process.

Therefore, even if interrupts are enabled during the entire system call processing period, the processing can proceed without malfunction.

As explained in detail about the invention, conventional operating systems to achieve multiprogramming do not have dedicated instructions for specifically manipulating data managed by the operating system, thus avoiding conflicts in access to shared data. To do this, we have taken measures such as protecting part of the system call processing from asynchronous interrupts.

Operating systems for multiprogramming are required to perform real-time processing, and in particular must have high interrupt responsiveness. However, due to the structure of the operating system, there are a large number of interrupt-disabled sections, and interrupts important to the system are sometimes not accepted, often resulting in the system not being able to be expected to operate normally.

The present invention has the advantage that by providing special dedicated instructions for the operating system in a processing device with simple hardware added, the interrupt-prohibited area is minimized as much as possible during processing of each system call, and interrupt responsiveness is greatly improved. has.

[Brief explanation of the drawing]

FIG. 1 is a block diagram of an example of a multiprogramming processing device of the present invention, and FIG. 2 is a flow diagram of processing of P and V instructions using dedicated instructions of the multiprogramming processing device of the present invention. , FIG. 3 shows an example of data transmission and reception between tasks, and FIG. 4 shows an example of data transmission and reception between tasks.
5 is a diagram showing the relationship between instructions, 5BNO-DATA instructions, and interrupt processing. FIG. and the sixth
The figure shows an example of common I10 access between tasks using a semaphore, FIG. 7 is a flow diagram of P and V instructions in a conventional multiprogramming processing device, and FIG. 8 is a system call P instruction. , ■ is a diagram showing the relationship between instructions and interrupt processing. [Main reference numbers] 1. Access bus, 2. Data bus, 3. Bus interface unit, 4. ALU, 5. General purpose register group, 6. Instruction queue, 7. Entry decoder, 8. ...Operand buffer, 9..Microprogram memory, 10..Selection signal generation section, 11..OS data management section, 12..Temporary latch, 13..Selector.

Claims (1)

[Claims] A multiprogramming processing device that executes a plurality of tasks in parallel, comprising dedicated instructions for manipulating data related to each task managed by an operating system, and means for storing information that the data has been manipulated by executing the dedicated commands. . A multiprogramming processing device characterized by comprising a determining means for permitting or disallowing manipulation of the data based on the storage state.