JPH0340035A - Multi-task processing system - Google Patents

Abstract

PURPOSE:To realize the multi-channel mechanism by a communication emulator by registering a request in an event list and actuating a dispatcher when some request is generated in the course of application operation, selecting a task to be executed from tasks in a ready state, and setting it to an operating state, and switching the task. CONSTITUTION:In the course of application operation, when a task A calls a service routine 41, this request is informed to an event manager 45 through a keyboard manager 44. The event manager 45 registers its request in an event list 47, informs it to a dispatcher 42, and the dispatcher 42 shifts the task which comes to a ready state earliest among the tasks of a ready state registered in a task list 46, to an executing state. Also, the task A in which an event is generated is registered as an event end waiting task. The task which comes to the executing state operates until a request to keyboard, a pipe and communication is issued, and switches the task. In such a way, a multi-channel mechanism can be realized by a communication emulator.

Description

DETAILED DESCRIPTION OF THE INVENTION [Objective of the Invention (Field of Industrial Application) This invention relates to a multitasking processing system that realizes multitasking operations on a single-tasking OS (operating system).

(Prior art) Conventionally, many communication terminals process multiple logical channels (hereinafter referred to as multichannel), and Figure 2 shows a simple processing example when trying to emulate this on a single O8. show. In the figure, reference numeral A indicates a check of the key buffer, and if the key strength matches, a key code is sent to the host device, and if there is not, it is notified. Symbol B is a reception buffer extraction process, which is F I F O (First In First
0ut) processed by the buffer. In addition, there is an area in the received data in which it is possible to identify which logical channel the data corresponds to. Reference numeral C denotes a multiplexer, and processing is divided for each channel depending on the identifier of the above-mentioned received data.

(Problem to be solved by the invention) According to the above conventional example, there is no problem as long as each channel is treated with equal priority, but if there is a difference in priority among each channel, there is a problem in buffer management. occurs. Also,
This is a problem if there is key manual processing as an extension of the processing of each channel, and furthermore, if priority is given to the key processing, this becomes even more of a problem, and a multi-channel response is required.

The present invention has been made in view of the above circumstances, and it is an object of the present invention to provide a multitask processing system that considers the processing of each channel as one task and realizes a multichannel mechanism in a communication emulator. Another purpose is to provide an environment in which programs can be created in a multitasking manner on a single O8 without task management, resource management, etc. necessary for multitasking.

[Structure of the Invention] (Means and Effects for Solving the Problems) The present invention provides a single-task processing system that incorporates an operating system that can only operate in a single task by itself, and a multiple processor that manages the operation of multiple tasks. In addition, the above-mentioned multiple processor has a keyboard manager that performs manual keyboard management, a pipe manager that notifies the event manager of event occurrence and termination for each file and performs inter-task communication, and a driver that controls external optional devices. It consists of an interface and an event manager that collectively manages requests from applications to each of the above managers. When a certain request occurs while an application is running, the event manager registers the request in the event list and starts the dispatcher. The dispatcher is configured to select a task that should be carried out from among tasks that are in a ready state, set it in an active state, and switch the task.

This makes it possible to implement a multi-channel mechanism in a communication emulator. In other words, it is possible to consider the processing of each channel as one task.

(Example) Embodiments of the present invention will be described below using the drawings.

FIG. 1 is a block diagram showing an embodiment of the present invention. In the figure, 1 is an application program, and tasks 1 to 4 process each logical channel. Reference numeral 2 denotes an option board section, which consists of a board and a driver that controls the board.

A driver has an interface to an application program. 3 is the hardware on the machine on which the invention functions.

4 is a multiple processor added according to the present invention, and is composed of the following components. A service routine 41 notifies each functional block of requests (events) from the application program 1 and the driver of the option board unit 2, and returns the status to the requester when the event ends. 42 is a dispatcher;
When the event ends, the tasks registered in the task list 42 in the ready state are put into the active state. 43 is a pipe manager, which handles events related to pipes.
The event manager 45 is notified of occurrence, termination, etc. 4
A keyboard manager 4 notifies the event manager 45 of the occurrence, termination, etc. of events related to keyboard input. 45 is an event manager, which displays an event list 47 for newly occurring events.
Register. When the event ends, it is deleted from the event list and the dispatcher 42 is notified. In the figure, TCB is a task control block and EVB is an event block.

The operation of the embodiment of the present invention will be explained below.

As an example, the application will be explained as a communication emulator. First, the option board 2 becomes a communication board that physically connects lines. Let's take an example of a moment when an application is running. At this time, it is assumed that task A is registered in the running list 46 and the other tasks are in the ready state. At this time, when task A calls the service routine 41 to obtain the user's key power, this request is passed through the keyboard manager 44 and the event manager 5
will be notified. The event manager 45 records the request as an unfinished key human power waiting event in the event list 4.
7 and notify the dispatcher 42. The dispatcher 42 shifts the task that becomes ready earliest among the ready state tasks registered in the task list 46 to the execution state. Also, the task that generated the event (task A in this case) is registered as a task waiting for the event to end. Once a task is in the running state, it continues to run until it issues a request for a keyboard, pipe, or communication. This is task switching.

Now, how does the event end? Taking task A registered in the event list 47 as a key wait event in the above example, it remains in this state until the user inputs a key. When a key is pressed manually, an interrupt occurs from the keyboard. This interrupt routine notifies the event manager 45 and removes the event from the event list 47.

The dispatcher 42 puts task A into a ready state. Since this operation is performed by an interrupt, it is performed even when other tasks are being executed.

In the case of a communication board, the driver notifies the user via a service routine that an interrupt has occurred.

Regarding pipes, the process goes through a service routine, and when a read request occurs in response to a write request, a write request triggers an event end event in response to a read request. As described above, a multitasking operation is performed.

[Effects of the Invention] As described above, according to the present invention, it is possible to realize a multi-channel mechanism in a communication emulator. In other words, it becomes possible to consider the processing of each channel as one task. Furthermore, this makes it possible to provide an environment in which programs can be created in a multitasking manner on the O8, which does not require task management, resource management, etc. necessary for multitasking.

[Brief explanation of drawings]

FIG. 1 is a block diagram showing an embodiment of the present invention, and FIG. 2 is a flow chart showing the operation of a communication emulator in a conventional example. DESCRIPTION OF SYMBOLS 1... Application program, 2... Option board part, 3... Hardware, 4... Multiple processors, 41... Service routine, 42...
...Dispatcher, 43...Pipe manager, 4
4...Keyboard manager, 45...Event manager, 46...Task list, 47...Event list.

Claims (1)

[Claims] A multi-processor that manages the operation of multiple tasks is added to a single-task processing system that has a built-in operating system that can only operate with a single task. A pipe manager that communicates between tasks by notifying the event manager of event occurrence and termination, an interface for a driver that controls external optional devices, and an event manager that centrally manages requests from applications to each of the above managers. When a certain request occurs during application operation, the event manager registers the request in the event list and starts the dispatcher, and the dispatcher
A multi-task processing system is characterized in that a task to be executed is selected from among tasks in a ready state, set to an operating state, and task switching is performed.