JP6702762B2 - Information processing apparatus, information processing apparatus control method, and program - Google Patents

Description

The present invention relates to an information processing device, a method for controlling the information processing device, and a program, and more particularly, to task execution of an information processing device that executes a plurality of tasks in the background under an environment where there are usage resource usage restrictions.

The following are possible system procedures for collecting the usage status from devices and transmitting the collected usage status to the management server on the Internet. First, a request for collecting the usage status is transmitted to the device to be collected, and the usage status log is acquired. Next, the acquired data is processed and transmitted to the management server.

Here, an environment in which execution resources are limited is conceivable as an environment for operating the system. Specifically, for example, background processing in a mobile terminal (device) can be mentioned. In a mobile terminal, the resources that can be used by a program operating in the background are limited in order to suppress battery consumption. In such an environment, when communicating with a device or a management server, if the response at the communication destination is slower than the available time of the CPU, and if the standby or another process is executed first, the CPU will be processed by the other process. It may be consumed and data communication may fail. Also, depending on the type of device, if the communication is canceled midway, it may not be possible to restart midway, and communication may continue from the beginning. In this case, even if a retry is made after the data communication fails, the communication may repeatedly fail and the communication may not be completed. In order to solve such a situation, it is necessary to control the allocation of the execution resources and the task control in consideration of the limitation of the execution resources.

Therefore, Patent Document 1 discloses a method for enabling a specific task to be executed more often by using a CPU for a specific task for a long time. In Patent Document 1, it is determined whether or not the process to be executed is a predetermined specific process, and if it is a predetermined specific process, a process of assigning an already assigned process to the specific process I do.

JP, 2011-186619, A

However, Patent Document 1 only allocates a CPU to a predetermined process, and does not consider a dynamic condition such as a response status of a device. In addition, it does not take into consideration the case that the process cannot be restarted halfway when it is canceled and the process must be performed from the beginning. Therefore, if the response at the communication destination is slower than the available time of the CPU, the communication failure may continue. In other words, when communicating with a device or server in an environment where execution resources are limited, if the response at the communication destination is slower than the available time of the CPU, standby or another process is executed first CPU is consumed and data communication fails. Further, when communication is canceled midway and communication cannot be resumed halfway and communication is performed from the beginning, even if retry is performed after data communication fails, the communication may repeatedly fail and the communication may not be completed.

In view of the above problems, the present invention provides an information processing apparatus capable of executing a plurality of tasks in the background even when communicating with a device or a server in an environment where execution resources are limited. That is the purpose.

In order to solve the above problems, an information processing apparatus of the present invention is an information processing apparatus for executing a plurality of tasks in the background, and execution means for executing a plurality of tasks, run by the execution means If the task is a task that cannot be restarted midway, and there is a CPU usage restriction, and standby processing for the task that cannot be restarted midway occurs , another task that is scheduled to be executed after the task in which the standby processing occurred And a canceling means for canceling.

According to the present invention, it is possible to provide an information processing apparatus capable of executing a plurality of tasks in the background even when communicating with a device or a server under an environment where execution resources are limited. As a result, when waiting occurs in a task that cannot be restarted midway in an environment where execution resources are limited, other tasks are canceled and the allocation of execution resources is concentrated on the task, and the task is completed within the execution resource limit. You can increase the probability that you can. Even if the execution of the task is not completed within the execution resource usage limit, if the number of retries exceeds a certain value, the task is executed only when the execution resource is not limited. Therefore, it is possible to prevent a situation in which a task that cannot be restarted midway cannot be completed repeatedly, and that affects other tasks, and it is possible to realize more efficient task processing.

It is a conceptual diagram which shows an example of the whole system structure. It is a block diagram which shows the hardware constitutions of a computer. It is a detailed diagram showing an example of the whole system configuration. It is a figure which shows the software structure of a background task. It is a figure which shows an example of the data structure of a client terminal. It is a flow chart which shows a series of processings of a client terminal. It is a flowchart which shows the task order determination process which concerns on 1st Embodiment. 6 is a flowchart showing a task execution process according to the first embodiment. It is a figure which shows the data transition of the execution queue with a restriction which concerns on 1st Embodiment. It is a flowchart which shows the task execution process which concerns on 2nd Embodiment. It is a flowchart which shows the task order determination process which concerns on 2nd Embodiment.

Hereinafter, the best mode for carrying out the present invention will be described with reference to the drawings. The system and method described in this specification collect, process, and transmit logs of each device. In the following description and in the drawings of the invention, parts that are well known to persons skilled in the art and are not necessary for understanding the description of the present invention will be omitted herein.

(First embodiment)
FIG. 1 is a conceptual diagram showing an example of the overall system configuration according to the present embodiment. This system includes a server computer 102, a client terminal 103, and a device 104, and each device is connected to the Internet 101 via a LAN 207. The Internet 101 is a communication line for exchanging information between the above-mentioned devices across a firewall. Through the Internet 101, the server computer 102, the client terminal 103, and the LAN 207 to which the device 104 belongs can communicate through a firewall. The device 104 refers to a personal computer (information processing device), a virtual PC that virtualizes an operation system of the personal computer, or a remote PC. Further, it may be an image forming apparatus, a built-in computer such as a printer or an MFP (multifunction peripheral). The LAN 207 and the Internet 101 are communication line networks that support the TCP/IP protocol, for example, and may be wired or wireless. In the present embodiment, each of the server computer 102 and the device 104 is shown as one unit, but it may be configured with a plurality of units or as a virtual PC.

FIG. 2 is a block diagram showing an example of the hardware configuration of the computer 200 according to this embodiment. Unless otherwise specified, the device may be a single device or a system composed of a plurality of devices as long as the functions of the present invention are executed. Further, unless otherwise specified, the present invention can be applied to a system in which a connection is made and a process is performed via a network such as a LAN, WAN, or the Internet, as long as the functions of the present invention are executed.

In the following description, the computer 200 may be any of the server computer 102, the client terminal 103, and the device 104. The computer 200 includes a CPU 201 that executes processing in which graphics, images, characters, tables (including spreadsheets), and the like are mixed based on a program ROM of the ROM 202 or a document processing program stored in the external storage device 205. .. The CPU 201 centrally controls each device connected to the system bus 204. In addition to these, an input/output device may be provided. In addition, the program ROM of the ROM 202 or the external storage device 205 stores an operating system, which is a control program of the CPU 201, various data, and the like. The RAM 203 functions as a main memory, a work area, etc. of the CPU 201, and the network I/F control unit 206 controls data transmission/reception with the LAN 207. In addition, the CPU 201 executes the processing based on the program stored in the external storage device 205, thereby realizing the software configuration of the computer 200 as shown in FIG. 4 described later and the processing of each step of the flowchart described later. It

FIG. 3 is a detailed diagram showing an example of the overall system configuration according to the present embodiment. First, it is assumed that there is a management server 301 accessible via the Internet 101. The management server 301 may have the same configuration as the server computer 102 shown in FIG. 1, and is a server for collecting the log data collected from the device A and the device B (104). Further, the client terminal 103 has a function of collecting logs from the device A and the device B (104), sending logs to the management server 301, and the like, and includes an application 302 and a background task 303. The application 302 is a program activated by an instruction from the user, and interacts with the user via a user interface (not shown). The application 302 can also start the background task 303 in response to a user instruction. The background task 303 is a program that operates in the background of the client terminal 103. Generally, it is activated from the operating system (hereinafter, OS) at regular intervals, but as described above, it may be activated from the application 302 in response to an instruction from the user. The device A and the device B (104) are directly connected to the Internet 101, receive the request from the client terminal 103, acquire the information in the own device, and transmit the log information.

Next, an example of the software configuration of the background task 303 in the client terminal 103 according to this embodiment is shown in FIG. The background task 303 has a function of collecting and transmitting the log of the device 104. Background tasks 303 can be classified into two types: data processing programs and information storage areas. The data processing program includes a task management unit 401, a task order determination unit 402, a task execution unit 403, a program status management unit 404, and a network I/F 405. The information storage area is composed of execution history information 406, task definition information 407, a limited execution queue 408, and an unlimited execution queue 409. The information storage area may be a file, a memory, or the like regardless of the data storage format, but it is desirable that the information storage area can be permanently stored in the same location as the data ROM of the ROM 202 or the external storage device 205. Further, the two queues of the restricted execution queue 408 and the unrestricted execution queue 409 may have the same configuration, and in the present embodiment, when the two queues are generally described, they are simply described as execution queues. To do.

The task management unit 401 is a processing unit that manages tasks to be executed. Its main role is to determine the tasks to be executed by this program, store them in a queue, and give instructions to each processing unit. The task management unit 401 also manages execution history information 406 and task definition information 407. The task order determination unit 402 has a role of changing the order of a plurality of tasks stored in the execution queue based on a certain condition. The processing performed by the task order determination unit 402 will be described later with reference to FIG. The task execution unit 403 is a processing unit that executes a plurality of tasks stored in the execution queue in a predetermined order. The program status management unit 404 manages the status and status of the program. Specifically, information such as what triggers this program was activated to start, whether available resources are limited, and whether available resources have been exceeded are managed through the OS. There is. Then, these pieces of information are notified to each processing unit. The network I/F 405 is a part that serves as an interface for connecting to an external network. Then, the task execution unit 403 can communicate with the management server 301 and the device 104 via the network I/F 405.

The execution history information 406 is an area for storing a history of executed tasks. Data is written out when the task is completed in this program or when the task is canceled midway, and is referred to when the program is started. The details will be described later with reference to FIG. The task definition information 407 is an area that defines the type of task executed by this program. The details will be described later with reference to FIG. The restricted execution queue 408 and the unrestricted execution queue 409 are queues that store tasks to be executed. The restricted execution queue 408 is a queue executed when the CPU operating this program has a usage restriction, and the unrestricted execution queue 409 is executed when there is no CPU usage restriction. The data in the execution queue is stored by the task management unit 401 and retrieved by the task execution unit 403. The details will be described later with reference to FIG.

Next, an example of the data structure of the client terminal 103 according to the present embodiment will be described with reference to FIG. Note that the main data handled in this embodiment is four pieces of execution history information 406, task definition information 407, restricted execution queue 408, and unrestricted execution queue 409 shown in FIG. 4, but is not limited to these.

FIG. 5A is a diagram showing an example of the data structure of the execution history information 406. The execution history information 406 includes a history ID 501, a task ID 502, a target device 503, a status 504, and a retry count 505. The history ID 501 is an identifier for uniquely identifying the task execution history. The task ID 502 is an identifier for uniquely identifying the content of the task, and is associated with the information stored in the task definition information 407. The target device 503 indicates to which device the task is directed. In the present embodiment, the name of the device is described, but it may not be the name as long as the device can be specified. The status 504 indicates the current execution status of the task, and there are three types: “unexecuted”, “in execution”, and “completed”. “Not executed” indicates that the target task has not been executed yet. “In progress” indicates that the target task is under execution. That is, it indicates that the program has not been completed when the program was started last time and the program has been canceled midway. “Completed” indicates that the target task is completed, and it is not necessary to execute the task any more.

FIG. 5B is a diagram showing an example of the data structure of the task definition information 407. The task definition information 407 includes a task ID 502, a processing content 506, and a task type 507. The processing content 506 indicates what kind of processing this task performs. In addition, in the present embodiment, there are three types of tasks of “log collection from device”, “log processing”, and “send log file to management server”. It may be. The task type 507 indicates the type of task, and in the present embodiment, is either “halfway restartable” or “halfway restart not possible”. Literally, "resumable in the middle" indicates that the task can be resumed from the middle even if it is canceled, and "impossible to resume in the middle" indicates that the task will be restarted from the beginning.

FIG. 5C is a diagram showing an example of the data structure of the execution queues (execution queue with limitation 408 and execution queue with no limitation 409). The execution queue includes a queue ID 508, a task ID 502, a target device 503, and a status 504. The queue ID 508 is an identifier that uniquely identifies the task in the queue, and the task having the queue ID 508 having a small number is preferentially executed. In this case, the log processing process for the device A is executed first, and the log file transmission process for the device B is executed last. In addition, in the present embodiment, unlike the status 504 of FIG. 5A, there are only two types, “unexecuted” and “in execution”. This is because completed tasks are not stored in the execution queue.

Next, an example of processing performed by the client terminal 103 will be described using a plurality of flowcharts. In the present embodiment, a case will be described where three types of tasks (a total of 6 tasks) shown in FIG. 5B are executed for two devices, device A and device B, in an environment where there is a CPU limitation. .. First, FIG. 6 is a flowchart showing an example of a series of processes of the client terminal according to the present embodiment, and two steps of a task order determination process (step S1) and a task execution process (step S2) are sequentially executed. .. The process of FIG. 6 is the same process in this embodiment and the second embodiment described later. Step S1 will be described in detail with reference to FIG. 7, and step S2 will be described in detail with reference to FIG.

Next, details of the task order determination processing for determining the task execution order, which is executed by the client terminal 103 according to the present embodiment, will be described using the flowchart shown in FIG. 7. As described above, this flow is started by the regular activation from the OS or the user's instruction. First, in step S11, the task management unit 401 acquires a task to be executed after starting the program from the execution history information 406 or the task definition information 407. It should be noted that in the present embodiment, the execution task acquisition process has two cases: a case where a new task is executed and a case where the task executed at the time of the previous program startup is executed midway. When a task is newly executed, since the execution history information 406 does not exist, the determined process is acquired from the task definition information 407. In the present embodiment, the defined processing is to execute the log collection processing from the device 104 described in FIG. 5 for the number of connected devices. In order to obtain this number of devices, the information of the device 104 registered in the OS is acquired. When executing from the middle, it recognizes that a task whose status 504 recorded in the execution history information 406 described in FIG. 5 is not “completed” is executed.

When the execution task can be acquired, in step S12, the task management unit 401 inquires of the program state management unit 404 whether or not there is a CPU usage restriction in the environment in which the program is operating. If there is no CPU restriction (No), the task to be executed is stored in the unexecuted execution queue 409, the present flow ends, and the process proceeds to the process of executing the task acquired in step S11. On the other hand, if there is a CPU limitation (Yes), it is considered necessary to execute the task in consideration of the limitation, and the task order determining unit 402 is instructed to determine the task order in steps S13 and S14. Further, the acquired task is stored in the restricted execution queue 408.

Next, in step S13, the task order determination unit 402 determines whether or not there is a task that cannot be restarted midway among the tasks acquired in step S11. If it does not exist (No), this flow is ended, and the process proceeds to task execution processing. On the other hand, if there is a task that cannot be resumed midway (Yes), the process proceeds to step S14, and the order is determined so that the task that cannot be resumed midway is preferentially executed. Specifically, among the tasks in the limited time queue 408, the tasks are rearranged so that the task whose task type 507 is "cannot be resumed" is executed first. By this processing, the tasks that cannot be restarted halfway are executed before the tasks that can be restarted halfway, so it is possible to give priority to CPUs for tasks that cannot be restarted halfway, and the CPU limit can be exceeded during processing. It is possible to reduce the sex. A specific example of order determination will be described later with reference to FIGS.

When the task order is determined, task execution processing (step S2: FIG. 6) is executed. FIG. 8 is a flowchart showing an example of task execution processing by the task execution unit 403. First, in step S21, the task execution unit 403 acquires an execution task from the execution queue. Specifically, if there is a CPU limitation, the task is obtained from the limitation execution queue 408, and if there is no CPU limitation, the task is obtained from the unlimited execution queue 409. Next, in step S22, the task execution unit 403 determines from the task ID 502 whether or not the task to be executed is a log collection task from the device 104. If it is not a log collection task (No), the process proceeds to step S2b and the task is executed. Then, when completed, it is determined in step S2c whether or not the next task exists. If the next task exists (Yes), the process returns to step S21 to execute the next task. On the other hand, if the next task does not exist (No), this flow ends. In the present embodiment, examples of tasks other than the log collection task include a processing task of collected logs and a log transmission task to the management server 301, but detailed description thereof is omitted because it is unnecessary for understanding the present invention. To do.

On the other hand, in step S22, if the task is a log collection task (Yes), the process proceeds to step S23. Then, in step S23, the task execution unit 403 executes the log collection task from the device 104. The task execution unit 403 issues a log request instruction to the device 104 registered in the OS via the network I/F 405. After issuing the request instruction, a response is returned from the device 104. Next, in step S24, the task execution unit 403 determines whether or not the content of the returned response is waiting. If it is not in standby (No), the process proceeds to step S25, and a log file is acquired. After that, this task is ended, and in step S26, it is determined whether or not the next task exists by observing the status of the execution queue. When the next task does not exist (No), this flow is ended, and when the next task exists (Yes), the process returns to step S21, and the task is executed in the same flow for the next task.

On the other hand, if the standby process occurs in step S24 (Yes), the process proceeds to step S27, and it is acquired via the program state management unit 404 whether or not there is a CPU restriction in the environment of the operation program. If there is no CPU restriction (No), this task can execute the task without considering the CPU usage restriction, so the process proceeds to step S2a and waits for a certain period of time. In this embodiment, since parallel processing by a plurality of threads is possible, it is possible to execute other tasks while waiting. Then, after the standby is completed, the process returns to step S23, and the task execution unit 403 again issues a log request instruction to the device 104 to acquire the log file.

On the other hand, if the CPU is restricted in step S27 (Yes), the process proceeds to step S28, and it is determined whether the task is a task that cannot be restarted midway. If the task cannot be restarted midway (No), the processing overhead does not occur because the task can be restarted midway even if the task is canceled midway under the CPU limitation. Therefore, the task can be executed without considering the CPU limitation, and the process proceeds to step S2a and waits for a certain period of time. On the other hand, if the task cannot be restarted midway in step S28 (Yes), if the task is canceled midway under the CPU limitation, the task will be restarted from the beginning and processing overhead will occur. Therefore, in order to attempt execution completion within the CPU limit, the process proceeds to step S29, the other tasks currently stored in the queue are canceled, and the CPU is not consumed by executing the tasks other than the task. That is, the task scheduled to be executed after the task to be executed is canceled. After canceling, the process proceeds to step S2a and waits for a certain period of time.

As described above, FIG. 8 shows an example of the task execution processing flow, but the present embodiment is not limited to the flow shown in the figure. For example, after determining in step S24 whether or not there is a CPU limitation when a standby occurs, it is determined whether or not the task cannot be restarted midway, but a flow in which the order of these two steps is interchanged may be used. .. Further, after the standby occurs, it is determined whether or not there is a CPU limitation. However, it is determined whether or not there is a CPU limitation before the task execution, and based on the information, the processing of step S28 and thereafter is executed. The order may be the order.

Next, FIG. 9 is a diagram showing an example of data transition of the restricted execution queue 408 in this embodiment. First, the data transition before and after the task order determination will be described with reference to FIGS. 9A and 9B, and next, the data transition before and after the task cancellation will be described with reference to FIGS. 9C and 9D.

FIG. 9A shows data in the restricted execution queue 408 before the task order is determined. As described with reference to FIG. 7, this data is data stored by the task management unit 401 based on the execution history information 406. In FIG. 9A, the log processing process for the device A (104) is being executed, that is, the task ended in a canceled state during the previous program startup is included. In addition, it also indicates that there are three other unexecuted tasks: a log file transmission process for the device A (104) and three tasks for the device B (104).

FIG. 9B shows data in the restricted execution queue 408 after the task order is determined. That is, the order is changed by executing step S14 from the state of FIG. 9(A). That is, in the state of FIG. 9A, the task order determination unit 402 acquires the task type 507 of the definition information 407 from the task ID 502 of the task of each queue. Then, when the task type 507 is “cannot be resumed midway”, the order of the queues is changed so that the tasks are preferentially executed. In this case, since the log collection processing from the device B (104) is a task that cannot be resumed midway, the queue ID 508 is changed from 0003 (scheduled to be executed third) to 0001 (scheduled to be executed first). .. Further, the tasks whose queue IDs 508 are stored in 0001 and 0002 are changed to queue IDs 0002 and 0003, respectively.

FIG. 9C shows data in the restricted execution queue 408 after the log collection processing from the device B (104). As compared with FIG. 9B, the task with the queue ID 508 is being executed, and thus the task is removed from the queue. From this state, the state of the restricted execution queue 408 after the task is canceled (step S29) is shown in FIG. As shown in the figure, in order to cancel all tasks other than the execution task and not allocate the CPU to other tasks, the queue is in an empty state.

As described above, in the present embodiment, when there is a CPU limitation in the task order determination processing, the order is determined by increasing the priority so that a task that cannot be resumed midway among the plurality of tasks is preferentially executed. Therefore, the CPU is preferentially assigned to the task. Further, in the task execution process, when a wait occurs for a task that cannot be restarted midway under the condition that the CPU is limited, the task is completed within the CPU limitation by executing another task to concentrate the CPU allocation on the task. It increases the probability that you can do it. By these processes, it is possible to reduce the case where a task that cannot be restarted midway cannot be completed repeatedly, and it is possible to realize efficient task processing.

(Second embodiment)
In the first embodiment, a case has been described where three types of tasks are executed for two types of devices in an environment where there is a CPU limitation. According to the first embodiment, it is possible to increase the probability that communication with a device is completed within the CPU limit by canceling other tasks and suppressing CPU consumption when it is necessary to wait for communication with a device. Became. However, task execution may not be completed if the network status or the response from the device is extremely slow. Therefore, in the present embodiment, error processing in the case where a task that cannot be restarted halfway fails under an environment where there is a CPU limitation will be described.

FIG. 10 is a flowchart showing an example of task execution processing performed by the task execution unit 403 according to this embodiment. Note that the task execution processing has already been described with reference to FIG. 8, and here a flowchart limited to error processing at the time of task failure, which is the point of this embodiment, is shown. First, a case where the CPU usage limit is exceeded during execution of a task will be described. While waiting for a certain period of time in step S2a, it is determined in step S31 whether the CPU limit has been exceeded. Specifically, the excess of the CPU limit is notified from the OS to the program state management unit 404, and then to the task execution unit 403. If there is no notification that the CPU limit has been exceeded (No), the process can be continued, and the process returns to step S23. On the other hand, if there is a notification that the CPU limit has been exceeded (Yes), this program will be forcibly terminated by the OS after the termination processing. In the ending process (step S32), the task management unit 401 stores the execution status in the execution history information 406, and at this time, the retry count 505 of the task currently being executed is incremented by 1. By this processing, it is possible to record the number of tries of the task.

Next, an example of the task order determining process performed by the task order determining unit in the present embodiment will be described using FIG. 11. In the present embodiment, a case will be described in which, after the flow described in FIG. 10 ends due to the CPU limit being exceeded, this flow is executed the next time the program is started. That is, in FIG. 10, the retry count is recorded in the execution history information 406 when the CPU limit is exceeded, but the task in the execution queue is moved based on the retry count.

After the execution history information is acquired in steps S11 and S12, if there is a CPU limitation (Yes in step S12), it is determined whether or not there is a task whose retry count 505 in the execution history information is a certain number or more. If there are a certain number or more of tasks (Yes), the task is regarded as a task that cannot be processed even if executed in an environment with CPU limitation, and the process proceeds to step S42. Then, in step S42, the task is moved from the restricted execution queue 408 to the unrestricted execution queue 409. As the threshold value of the number of retries, a fixed value may be held in the program, a setting file may be prepared and described, and the value may be read from the setting file when the program is executed.

As described above, in the present embodiment, the process of storing the number of retries when the execution of the task is not completed within the CPU usage limit, and moving the queue so as not to execute when the number of retries exceeds a certain value when the CPU is restricted is executed. To do. As a result, it is possible to prevent an execution error from occurring permanently and affecting other tasks, and it is possible to realize more efficient task processing.

(Other embodiments)
The present invention supplies a program that implements one or more functions of the above-described embodiments to a system or apparatus via a network or a storage medium, and one or more processors in a computer of the system or apparatus read and execute the program. It can also be realized by the processing. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.

Although the preferred embodiments of the present invention have been described, the present invention is not limited to these embodiments, and various modifications and changes can be made within the scope of the gist thereof.

Claims (9)

An information processing device that executes a plurality of tasks in the background,
Executing means for executing the plurality of tasks,
A task task in the middle resume not to run in the execution unit, and there are restrictions on the use of CPU and if the standby processing of the middle Resume Call task occurs, since the task of the standby processing has occurred Canceling means to cancel other tasks scheduled to be executed in
An information processing apparatus comprising: There are restrictions on the use of the CPU, and the plurality of cases where there is the middle resume not tasks in the task, the plurality of tasks the tasks of the middle Resume Call to preferentially executed to run in the execution unit Further has a determining means for determining the execution order of
The information processing apparatus according to claim 1, wherein the execution unit executes the plurality of tasks based on the execution order determined by the determination unit. The execution means, if said other task has been canceled by the canceling means, a predetermined time, the information processing apparatus according to claim 1 or 2, characterized in that the wait for execution of the task. Before you line means, and the task satisfies a predetermined condition that the standby processing has occurred, the <br/> controlling the tasks to which the standby processing occurred so as to run in situations without the restriction of the use of CPU The information processing apparatus according to claim 3, characterized in that The information processing apparatus according to claim 4 , wherein the case of satisfying the predetermined condition is a case where the use restriction of the CPU is exceeded a predetermined number of times or more . The information processing apparatus according to claim 2, wherein the determining unit acquires information regarding a usage restriction of the CPU from an operating system and determines the execution order based on the acquired information. .. The middle Resume Call task, the information processing apparatus according to any one of claims 1 to 6, characterized in that a logging task of the image forming apparatus. A method for controlling an information processing device, which executes a plurality of tasks in the background ,
An execution step for executing the plurality of tasks,
Wherein an execution step odor Te perform the task is in the middle resume Call task, and there are restrictions on the use of CPU and if the standby processing of the middle Resume Call task occurs, the task of the standby processing has occurred A cancellation process to cancel other tasks scheduled to be executed later,
A method for controlling an information processing device, comprising: Program for causing a computer to function as each unit of the information processing apparatus according to any one of claims 1-7.

Images