JP3870730B2 - Task management system - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a task management system suitable for application to an operating system (OS), for example.
[0002]
[Prior art]
Conventionally, it has been an important design goal of a real-time OS to increase the effective use of processor time that can be occupied by task execution while ensuring that the upper limit of the response time of a task is below a specified value that becomes a deadline. It was one of. In order to achieve this design goal, it is conceivable to employ a better dispatch policy.
[0003]
As one of such dispatch policies, an EDF (Earlist Deadline First) policy (reference documents: CL Liu and JW Layland, “Scheduling algorithms in multi-programming in a harden- rent realtime,” Vol. 20, No. 1, pp. 46-61, 1973.) is known. The EDF policy is known to be able to achieve the highest processor utilization rate among the methods for scheduling periodic tasks having the same period as the deadline. However, there are preconditions such as no interference between tasks and the number of processors being one.
[0004]
On the other hand, in order to realize stable operation of the system, the system is divided into a plurality of modules, and each is executed in a different address space, so that the data of other modules is not accidentally destroyed. Has been made up.
[0005]
Also, in general, each task cannot cross individual module boundaries. In a system configured as described above, a mechanism for calling a procedure in a different address space is often provided in order to make it possible to use a function of another module from one module.
[0006]
However, in this case, it is necessary to stop or start the client task and the server task every time the service is used. Depending on the time it takes to provide the service, often the time taken to stop or start is a non-negligible percentage of the total service time. Furthermore, since the scheduler employing the EDF policy tends to increase overhead as compared with the conventional scheduler, this problem can be further exacerbated.
[0007]
Furthermore, it is necessary to consider an increase in overhead accompanying a change in server task priority. In general, since the urgency of client tasks varies, it is desirable that the server task processes requests with the same priority as the client task.
[0008]
Therefore, the server task priority is often changed in accordance with the client task priority at the time of service request. The occurrence of overhead associated with the priority change or stop adds to the overhead associated with the start or stop of the server task and the client task.
[0009]
[Problems to be solved by the invention]
However, the above-described scheduler employing the conventional EDF policy has a disadvantage that the overhead becomes larger than the static priority scheduler using a fixed priority widely used in the conventional OS.
[0010]
In addition, when changing the priority of a server task according to the priority of a client task at the time of a service request, the overhead that accompanies the change or stop of the priority becomes the overhead associated with the start or stop of the server task and the client task. In addition, there is a disadvantage that the overhead is further increased.
[0011]
Therefore, the present invention has been made in view of the above points, and in order to reduce overhead, it is possible to start or stop a server task without operating the dispatch queue, and to operate the dispatch queue. It is an object of the present invention to provide a task management system that can inherit the priority without having to do so.
[0012]
[Means for Solving the Problems]
The task management system of the present invention is a task management system that manages tasks by a single processor, and includes a first data block that holds information related to task scheduling among information related to an arbitrary task, A second data block for holding information not recorded in the data block, a third data block provided for selecting the highest priority among the executable tasks, and other data blocks. It is activated by a service request from a task operating in the module, and includes a server task that processes the service request and a client task that issues a service request to the server task.
[0013]
In particular, the task management system of the present invention divides and manages information related to one task into a first data block and a second data block, and inserts the first data block into the third data block or The server task is a special task that is subject to deletion and does not have its own first data block, and other tasks inherit the start or end of the server task and the client task, and the priority of a certain task. In this case, only the correspondence between the first data block and the second data block is changed.
[0014]
  Mutex: Mutual Exclusion (Mutex: Mutual Exclusion) that uses the priority inheritance protocol to prevent the execution of two tasks at the same time is due to priority inheritance as one of the reasons why the overhead is larger than a normal mutex. A change in priority can be mentioned. Generally, when the priority of a task changes, it is necessary to perform some operation on the dispatch queue. This is expensive to operateEDFThis is especially a problem for the scheduler.
[0015]
With this division, it is possible to inherit the activation or termination of the server task and the client task and the priority only by changing the correspondence between the two. Thereby, although the client task is stopped, the positional relationship in the data structure of the first data block is not changed, and only the relationship of the first data block is changed.
[0016]
Also, from the current effective association indicating one pointer to the second data block from the first data block before activation, from the first data block to the second data block after activation, A process equivalent to movement is performed only by an operation for updating to a currently valid association indicating one pointer.
[0017]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below.
The task management system of the present embodiment efficiently realizes priority inheritance when a client task makes a service request to a server task, for example.
[0018]
[Means for Solving the Problems]
  The task management system of the present inventionOneDepending on the processorpluralIn the task management system that manages tasks, it is provided to select the highest priority task that can be executed.Dispatch queueAnd a server task that is activated by a service request from a task operating in another module and processes the service request, a client task that issues a service request to the server task,Service wait queue, which is a data structure that records service requests waiting to be processedWith information about one task,Activity that holds information related to scheduling of the task including at least priority information of the taskWhenContext holding information not recorded in the above activityDivided and managed as aboveactivityThe aboveDispatch queueThe above server task is subject to its own insertion or deletion.Activity aboveHaveZWhen other tasks inherit the start or end of the server task and the client task and the priority of a task,Using the dispatch queue and the service waiting queue,the aboveactivityAnd abovecontextChange only the correspondence ofProcess byIt is what I did.
[0019]
  In addition, the present inventionTask management methodIsIn a task management method for managing a plurality of tasks by a single processor, information relating to one task is recorded in an activity holding at least information related to scheduling of the task including priority information of the task and the activity. It is divided into contexts that hold information that is not managed, and the above activities are subject to insertion or deletion to the dispatch queue provided to select the highest priority task that can be executed. A server task that is started by a service request from a task running in another module and processes the service request does not have its own activity, and issues a service request to the server task and the server task. A client task Alternatively, when another task inherits the termination and priority of a task, the activity and the context are used by using the dispatch queue and a service wait queue that is a data structure for recording a service request waiting for processing. The processing is done by changing only the correspondence ofIs.
[0020]
By this division, the server task can be started or terminated and the priority can be inherited only by changing the correspondence relationship between the context 4 and the activity 2.
[0021]
In FIG. 1, the dispatch queue (dispatch_queue) 1 performs the most urgent association (the_most_urgent_activity) D1 based on the priority with respect to the activity (activity) 2.
[0022]
Activity 2 is performing the latter successor D2 of the column to itself. The priority (priority) 3 performs the former predecessor D3 of the column for the activity (activity) 2.
[0023]
The context 4 performs an original association (base_activity) D4 that is not related to the priority 3 with respect to the activity 2. The activity 2 performs a currently valid association (effective_context) D5 with respect to the context 4.
[0024]
The context 4 performs an association (effective_activity) D <b> 6 that is currently valid for the activity 2.
[0025]
FIG. 2 shows how the correspondence changes before and after the server task is activated.
FIG. 2 is a diagram illustrating changes in the relationship between contexts and activities due to server activation. FIG. 2 shows a state in which the correspondence between contexts and activities changes before and after the activation of the server shown in FIG. 2B from before activation shown in FIG. 2A. Here, since the object of queuing is an activity, and an activity that cannot be executed is queued as will be described later, this data structure is called a dispatch queue (the dispatch_queue).
[0026]
As can be seen from FIG. 2, the activity C14 remains in the same position in the dispatch queue 11 even though the client task 12 is stopped, and the activity C14 is the same as the activity C14. Only the relationship between the context S16 and the context C13 has changed.
[0027]
Even when a plurality of clients (clients) request the service (a_service) 15, it is guaranteed that the priority of the server task is always increased by priority inheritance unless the execution of the server task is interrupted. Therefore, there is no possibility that the dispatcher selects a context corresponding to these clients as a dispatch target. Therefore, it is not necessary to remove the activity C14 associated with the client task 12 from the dispatch queue 11 (the_dispatch_queue) 11.
[0028]
  Also, from the activity (activity) C14 before activation shown in FIG. 2A to the context (context) C13, from the current effective association (effective_context) D1 indicating one pointer, the activity (activity) after activation shown in FIG. 2B is displayed. ) From C14 to context S16,Pointer to the currently valid mapping(Effective_context) Processing equivalent to movement is performed only by an operation of updating to D4.
[0029]
  Further, in the technique shown in the conventional technique, the activity C14 is sent to the dispatch queue (the)._In the method according to the present embodiment, the activity C14 is not changed from the dispatch queue (the)._(dispatch_queue) 11 is left. This process can be omitted by delay dequeuing described later.
[0030]
Here, the change in the correspondence between the two is determined by the context S16 associated with the server context (server_context) of the service (a_service) 15, and the change in the correspondence is recognized.
[0031]
In FIG. 2A, an activity C14 performs a currently valid association (effective_context) D1 with respect to a context C13.
[0032]
The service (a_service) 15 performs an association D2 of the server context (server_context) with respect to the context (context) S16.
[0033]
In FIG. 2B, the activity 14 performs an effective association (effective_context) D4 for the context S16.
[0034]
The service (a_service) 15 performs an association D3 that records the current service (in_service) for the context C13.
[0035]
The service (a_service) 15 performs an association D2 of the server context (server_context) with respect to the context (context) S16.
[0036]
Here, a problem arises when the condition that the execution of the server task is not interrupted cannot be satisfied. For example, this is the case when the server task is stopped due to waiting for input processing (I / O) or the like.
[0037]
In this case, the activity C14 of the client task (client task) 12 associated with this task is removed from the dispatch queue (the dispatch_queue) 11.
[0038]
As a result, as shown in FIG. 3 to be described later, the activity (activity) C2 (27) of the client task (client task) 25 that should have stopped after waiting for service completion can be selected as a dispatch target. There is sex.
[0039]
In order to solve this problem, the client task (client task) 12 waiting for service completion checks whether the execution of the service (a_service) 15 is completed after being dispatched. If it has not been completed, the activity C14 corresponding to itself is removed from the dispatch queue (the dispatch_queue) 11. Here, postponing the process of removing the activity C14 from the dispatch queue (the dispatch_queue) 11 in this way is referred to as delay dequeuing.
[0040]
FIG. 3 is a diagram illustrating the execution of an inappropriate activity due to the sleep of the server task.
In FIG. 3, when the server task is stopped during service, the activity C 1 (24) is removed from the dispatch queue (the dispatch_queue) 21.
[0041]
This may select an activity C1 (24) that has a lower priority and would otherwise not be executed.
[0042]
At this time, the context C2 (26) is in a state of continuing the processing after the service ends.
[0043]
Therefore, even if the service has not ended, it behaves as if the service has ended.
[0044]
In FIG. 3, a context (context) C1 (23) of a client task (client task) 22 performs an association D11 that records the current service (in_service) for the service (a_service) 31.
[0045]
The service (a_service) 31 performs an association D12 of the server context (server_context) to the context (context) S32.
[0046]
The activity (activity) C1 (24) of the client task (client task) 22 performs a currently valid association (effective_context) D13 with respect to the context (context) S32.
[0047]
The service (a_service) 31 performs a correspondence (is_queued) D14 that waits in line for the context (context) C2 (26) of the client task (clienttask) 25.
[0048]
The activity (activity) C2 (27) of the client task (client task) 25 performs a currently valid association (effective_context) D15 with respect to the context (context) C2 (26).
[0049]
The service (a_service) 31 performs a correspondence (is_queued) D16 that waits in turn for the context (context) C3 (29) of the client task (clienttask) 28.
[0050]
The activity (activity) C3 (30) of the client task (client task) 28 performs an association (effective_context) D17 that is currently valid for the context (context) C3 (29).
[0051]
FIG. 4 is a diagram showing classes related to the realization of the service request mechanism and the relationship between them.
The dispatch queue (dispatch_queue) 31, the activity (activity) 32, and the context (context) 34 in the figure are as described above.
[0052]
Here, the other two classes will be described. Each of these two classes has the following functions.
[0053]
First, the service class 37 will be described.
The service class 37 is a class that represents a certain service, generally a procedure that can be called from different address spaces. Each service (service) is associated with one server task. The context 34 of the service class 37 can be referred to via a pointer by the association D33 of the server context (server_context). The service class 37 is generated by an application program.
[0054]
Second, the service request (service_request) class 35 will be described.
The service request (service_request) class 35 represents a service request by a certain task. The client task (client task) continues to exist from when the service is requested until the server task completes providing the service.
[0055]
The attribute inheriting 36 is set to true when inheritance of priority to the server task occurs during processing of the service request, and false otherwise. Become.
[0056]
The service request (service_request) class 35 is generated by the context of the client task (client task).
[0057]
Next, the relationship between objects will be described.
These classes do not operate independently, but hold the_first_request, for example, as an association of references to objects of other classes as shown in FIG. These references are needed to construct the data structures listed below.
[0058]
  First, the service waiting queue will be described.
  A server task requests a serviceProcessing (in_service)That is,AhIf a pointer to the service request (service_request) object is stored, the server task waits until the execution of the server task is completed. The service wait queue is a data structure that records a service request that has been waited in this way. The service waiting queue is configured as a bidirectional link list having a service request (service_request) object 35 as an element.
[0059]
The first request association (the_first_request) D29 of the service object 37 indicates the top element.
[0060]
The latter association (successor) D27 of the column of the service request (service_request) object 35 is a pointer to the subsequent elements 35-1, 35-2,..., And the former association (predecessor) D30 of the column is the preceding. Is a pointer to the elements 35-1, 35-2,. The (predecessor) D30 of the first element 35 and the (successor) D27 of the last element 35-n respectively hold special pointer values that do not point to any object. Note that a null pointer can be used for this purpose when implemented in the C, C ++ language.
[0061]
In FIG. 4, the dispatch queue (dispatch_queue) 31 performs the most urgent association (the_most_urgent_activity) D21 based on the priority with respect to the activity (activity) 32.
[0062]
The activity 32 performs the latter successor D22 of the column to itself. The priority 33 performs the former predecessor D23 in the column for the activity 32.
[0063]
The context 34 performs an original association (base_activity) D24 that is not related to the priority 33 with respect to the activity 32. The activity 32 performs an association (effective_context) D <b> 25 that is currently valid for the context 34.
[0064]
The service request (service_request) class 35 associates a context (the_text) D26 with the context (context) 34.
[0065]
The service class 37 performs first request association (the_first_request) D29 with respect to the service request (service_request) class 35.
[0066]
The service request (service_request) class 35 performs a waiting-for association (waiting_for) D28 with respect to the service (service) class 37.
[0067]
The service request (service_request) class 35 performs the latter successor D27 in the column for 35-1, 35-2,. The service request (service_request) class 35 performs the former predecessor D30 of the column for 35-1, 35-2.
[0068]
The service request (service_request) class 35 performs an association D31 of a requesting activity (requesting_activity) to the activity (activity) 32.
[0069]
  The service class 37 is in response to the service request (service_request) class 35.Processing service(In_service) Correlation D32 is performed.
[0070]
The service class 37 performs an association D33 of a server context (server_context) with a context (context) 34.
[0071]
Next, service request operations and server processing procedures will be described below.
FIG. 5 is a flowchart showing the operation of the service request procedure. The service request procedure shown in FIG. 5 shows the operation of the service class 37. Each process corresponds to FIG. 4 described above.
[0072]
  In FIG. 5, in step S1, a service request (service_request) object 35 is generated. In step S2, it is determined whether the server task is busy. When the server task is busy in step S2, the process proceeds to step S3. In step S3,Processing serviceBased on the attribute inheriting 36 by the (in_service) association D32, it is determined whether or not the inheritance of the priority to the server task has occurred during the processing of the service request.
[0073]
  If the priority is inherited to the server task in step S3, the process proceeds to step S4. In step S4, the first request(The_first_request) From the service request 35 associated with D29Requesting activity (requesting_activity) D31In association with activity 32,First request(The_first_request) From the service request 35 associated with D29contextThe activity 32 and the context 34 are associated with each other by associating the context 34 with the correspondence D26 of (the_context).
[0074]
In step S5, the generated service request (service_request) object 35 is inserted at the head of the service waiting queue.
[0075]
  If the server task is not busy in step S2, the process proceeds to step S6. In step S6,Processing service(In_service) The association D32 is set to refer to the generated service request (service_request) object 35.
[0076]
  When the priority is not inherited to the server task in step S3, the process proceeds to step S7. In step S7,Processing service(In_service) D32From service request 35 associated withRequesting activity (requesting_activity) D31Is associated with activity 32, and service processing is in progress(In_service) D32From service request 35 associated withcontextThe activity 32 and the context 34 are associated with each other by associating the context 34 with the correspondence D26 of (the_context).
[0077]
Specifically, an activity at the time of service request is associated with a client context currently in service.
[0078]
  In step S8,Processing service(In_service) In the attribute inheriting 36 based on the association D32, a true indicating that the inheritance of the priority to the server task has occurred during the processing of the service request is made. .
[0079]
In step S9, the association D33 between the current activity (activity) 32 and the server context (server_context) is associated. Specifically, the activity (activity) of the head client is associated with the server context (server_context).
[0080]
In step S10, the server context (server_text) association D33 is dispatched. At this time, the client context is retained.
[0081]
In step S11, it is determined whether or not the service is completed. When the service is completed in step S11, the service request is immediately successful.
[0082]
If the service is not completed in step S11, the process proceeds to step S12. In step S12, the current activity 32 is removed from the dispatch queue (dispatch_queue) 31. Specifically, correct dispatch correction processing is performed. This processing corresponds to the removal of the activity C2 (27) of the client task (client task) 25 shown in FIG.
[0083]
In step S13, rescheduling is performed, the process returns to step S11, and the determination and processing from step S11 to step S13 are repeated. Specifically, processing is performed so as to dispatch the other party that should originally be dispatched.
[0084]
FIG. 6 is a flowchart showing the operation of the server processing procedure. FIG. 6 shows the operation of the server context.
In FIG. 6, the service is executed in step S21.
[0085]
  In step S22,Processing serviceBased on the attribute inheriting 36 by the (in_service) association D32, it is determined whether or not the inheritance of the priority to the server task has occurred during the processing of the service request.
[0086]
  When the priority inheritance to the server task does not occur in step S22, the process proceeds to step S23, and c is set in step S23.Processing service(In_service) Associating the context with the association D32 (the_context) D26. Specifically, it is associated with the context of the client that currently provides the service. In step S24, it is determined whether the waiting queue is empty.
[0087]
  When the waiting queue is not empty in step S24, the process proceeds to step S25, and in step S25,Processing service(In_service) The head element of the waiting queue is assigned to the association D32.
[0088]
  In step S26, the head element of the waiting queue is removed. In step S27,Processing serviceCorrespondence D31 of requesting activity (requesting_activity) by (in_service) mapping D32Activity 32Determines whether it has been delayed dequeued. Specifically, this is processing when delayed dequeuing is performed while queued.
[0089]
If the delay dequeue has been completed in step S27, the process proceeds to step S28. If the delay dequeue has not been completed in step S27, the process proceeds to step S29.
[0090]
  In step S28,Processing serviceCorrespondence D31 of requesting activity (requesting_activity) by (in_service) mapping D32Activity 32Is inserted into the dispatch queue (dispatch_queue) 31.
[0091]
  In step S29,Processing serviceCorrespondence D31 of requesting activity (requesting_activity) by (in_service) mapping D32Activity 32Is associated with the association D33 of the server context (server_context).
[0092]
  In step S30, c is dispatched, the process returns to step S21, and the processes and determinations from step S21 to step S30 are repeated. Specifically, beforeProcessing service(In_service) The client that has been associated D32 is dispatched. At this time, the previous activityThe context associated withThere is no need to dispatch.
[0093]
  When the priority inheritance to the server task occurs in step S22, the process proceeds to step S31, and in step S31,Processing serviceCorrespondence D31 of requesting activity (requesting_activity) by (in_service) mapping D32Activity 32Determines whether it has been delayed dequeued.
[0094]
If the delay dequeue has been completed in step S31, the process proceeds to step S32. If the delay dequeue has not been completed in step S31, the process proceeds to step S33.
[0095]
  In step S32,Processing serviceCorrespondence D31 of requesting activity (requesting_activity) by (in_service) mapping D32Activity 32Is inserted into the dispatch queue (dispatch_queue) 31.
[0096]
  Specifically, the previous activity has a lower priority than the current activity and is associated with the server context, so the previous activityThe context associated withThere is no need to dispatch.
[0097]
  In step S33,Processing service(In_service) The head element of the waiting queue is assigned to the association D32. At this time, the association D32 that records the current service (in_service) is set to indicate the first service request.
[0098]
In step S34, the head element of the waiting queue is removed, the process returns to step S21, and the processes and determinations from step S21 to step S30 are repeated. At this time, the server context has been moved by the activity associated with the first service request.
[0099]
  When the waiting queue is empty in step S24, the process proceeds to step S35, and in step S35,Processing service(In_service) Assign NULL to the association D32. At this time, the server is idling.
[0100]
In step S36, c is dispatched, the process returns to step S21, and the processes and determinations from step S21 to step S30 are repeated. When the server context (server_context) mapping D33 is dispatched in step S10 shown in FIG. 5, it stops when c is dispatched in step S36.
[0101]
As described above, in order to improve the stability of the system, it is effective to divide the system into a plurality of modules and execute them in different address spaces.
[0102]
In addition, in order to request a service to a module existing in a different address space, a mechanism is provided in which a server task executes a service in response to a client task service request.
[0103]
At this time, the server task is often implemented so as to inherit the priority of the client task so that processing according to the urgency of the client task can be performed.
[0104]
On the other hand, in order to achieve a higher processor utilization rate, it is effective to use a scheduler that employs an EDF policy. However, when a scheduler that employs an EDF policy is used, the overhead associated with task activation or termination and priority change tends to increase compared to the conventional method. For this reason, there has been a problem that the efficiency of the service request mechanism decreases.
[0105]
Therefore, according to the technique proposed in the present embodiment, the following optimization can be performed, which has an effect of avoiding the problem of high overhead due to dispatch queue (dispatch_queue) operation of EDF scheduling.
[0106]
First, the server task is started or terminated without manipulating the data structure representing the dispatch queue (dispatch_queue). As a result, the problem of high overhead due to the dispatch queue (dispatch_queue) operation of EDF scheduling can be avoided.
[0107]
Second, the server task can inherit the priority of the client task without manipulating the data structure representing the dispatch queue (dispatch_queue). As a result, it is possible to construct a highly stable system and achieve a higher processor utilization rate while suppressing an increase in overhead associated with server task activation accompanying EDF scheduling and priority inheritance.
[0108]
Further, by combining this method with a power saving real-time scheduling method, a higher power consumption reduction effect can be obtained.
[0109]
【The invention's effect】
The task management system according to the present invention is a task management system that manages tasks by a single processor, and includes a first data block that holds information related to task scheduling out of information related to an arbitrary task; A second data block for holding information not recorded in the data block, a third data block provided for selecting the highest priority among the executable tasks, and other data blocks. A server task that is activated by a service request from a task operating in a module and processes the service request, and a client task that issues a service request to the server task. Divided into a block and a second data block and managed, and the first data block is The server task is a special task that does not have its own first data block, the start or end of the server task and the client task, and the priority of a certain task. When another task inherits, since only the correspondence between the first data block and the second data block is changed, first, the server is operated without operating the third data block. By starting or ending a task, it is possible to avoid the problem of high overhead due to the operation of the third data block of EFD scheduling.
[0110]
Second, it allows the server task to inherit the priority of the client task without manipulating the third data block. As a result, it is possible to achieve a highly stable system construction and a higher processor utilization rate while suppressing an increase in overhead associated with server task activation involving EDF scheduling and priority inheritance.
[0111]
In the task management system of the present invention, even if the client task is stopped due to waiting for a service request from the server task in the above, the client task is erroneously deleted without immediately deleting the client task from the third data block. Since the operation on the third data block is postponed until it is found that the data is selected from the three data blocks, the number of operations on the third data block associated with the stop / start of the client task can be reduced. Play.
[Brief description of the drawings]
FIG. 1 is a diagram showing contexts and activities applied to the present embodiment.
FIG. 2 is a diagram illustrating a change in a relationship between a context and an activity due to server activation. FIG. 2A is before activation, and FIG. 2B is after activation.
FIG. 3 is a diagram illustrating execution of an inappropriate activity due to a sleep of a server task.
FIG. 4 is a diagram showing classes related to the realization of the service request mechanism and the relationship between them.
FIG. 5 is a flowchart showing an operation of a service request procedure.
FIG. 6 is a flowchart showing an operation of a server processing procedure.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1 ... Dispatch queue (dispatch_queue), 2 ... Activity (activity), 3 ... Context (context), 11 ... Dispatch queue (dispatch_queue), 12 ... Client task (client task), 13 ... Context (context) ) C, 14 ... activity C, 15 ... service (a_service), 16 ... context (context) S, 21 ... dispatch queue (dispatch_queue), 22 ... client task (client task), 23 ... ... Context C1, 24 ... Activity C1, 25 ... Client task (client) task), 26... Context C2, 27... Activity C2, 28... Client task (client task), 29... Context C3, 30. …… Service (a_service), 32 …… Context (context) S, 31 …… Dispatch queue (dispatch_queue), 32 …… Activity, 33 …… Priority (priority), 34 …… Context (context), 35 …… Service request class, 36 …… Inheriting attribute, 37 …… Service (service) e) Class

Claims (4)

In a task management system that manages multiple tasks with one processor,
A dispatch queue provided to select the highest priority task that can be executed;
A server task that is activated by a service request from a task operating in another module and processes the service request;
A client task that issues a service request to the server task, and
A service waiting queue that is a data structure for recording service requests waiting to be processed ;
Information related to one task is divided and managed into an activity holding information related to scheduling of the task including at least priority information of the task and a context holding information not recorded in the activity ,
The above activity is the target of insertion or deletion to the dispatch queue ,
The server task does not have its own activity ,
When other servers inherit the start or end of the server task and the client task, and the priority of a task, only the correspondence between the activity and the context using the dispatch queue and the service waiting queue A task management system characterized in that processing is performed by changing. The task management system according to claim 1,
Even if the client task stopped for service request waiting from the server task immediately without deleting the client task from the dispatch queue, task management, characterized by postponing operations on the dispatch queue system. In a task management method for managing a plurality of tasks by one processor,
Information related to one task is divided into an activity holding information related to scheduling of the task including at least priority information of the task and a context holding information not recorded in the activity, and managed.
Among the tasks that can execute the above activities, the task with the highest priority is selected for insertion or deletion into the dispatch queue.
A server task that is started by a service request from a task operating in another module and processes the service request does not have its own activity.
When starting or ending a client task that issues a service request to the server task and the server task, and when another task inherits the priority of a task, record the service request waiting for the dispatch queue and processing A task management method characterized in that processing is performed by changing only the correspondence between the activity and the context using a service waiting queue that is a data structure to be processed. The task management method according to claim 3,
Task management characterized in that even if the client task is stopped due to waiting for a service request from the server task, the operation on the dispatch queue is postponed without immediately deleting the client task from the dispatch queue. Method.

Images