WO2007108133A1 - マルチプロセッシング方法及びマルチプロセッサシステム - Google Patents

マルチプロセッシング方法及びマルチプロセッサシステム Download PDF

Info

Publication number
WO2007108133A1
WO2007108133A1 PCT/JP2006/305867 JP2006305867W WO2007108133A1 WO 2007108133 A1 WO2007108133 A1 WO 2007108133A1 JP 2006305867 W JP2006305867 W JP 2006305867W WO 2007108133 A1 WO2007108133 A1 WO 2007108133A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
procedure
execution
server
processor
Prior art date
Application number
PCT/JP2006/305867
Other languages
English (en)
French (fr)
Inventor
Takahisa Suzuki
Makiko Ito
Hideo Miyake
Original Assignee
Fujitsu Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Limited filed Critical Fujitsu Limited
Priority to PCT/JP2006/305867 priority Critical patent/WO2007108133A1/ja
Priority to JP2008506135A priority patent/JP5003673B2/ja
Publication of WO2007108133A1 publication Critical patent/WO2007108133A1/ja
Priority to US12/235,209 priority patent/US20090019259A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration

Definitions

  • the present invention relates to a multiprocessing method and a multiprocessor system, and in particular, a multiprocessing method and a manolet processor that are executed by assigning, to a server processor, a plurality of program units stored sequentially in a client processor power sequential execution program. About the system.
  • a multi-processor system in which a plurality of processors are connected to each other via a communication path, and the processes are shared and executed.
  • each processor is an equivalent system, one processor is a client processor (machine), the other processor is a server processor (machine), and the client processor assigns processing to each server processor.
  • client processor assigns processing to each server processor.
  • server processor machine
  • client processor assigns processing to each server processor.
  • client-server system that processes the results.
  • the present invention relates to a client / server multiprocessor system.
  • FIG. 1 is a diagram showing a schematic configuration of a shared memory multiprocessor system. As shown in FIG. 1, this system has a shared bus 2 and a plurality of processors 1-0, 1-1, 1-2,..., 1-N and a shared memory 3 connected to the supply bus 2. .
  • each processor writes the data to be transmitted to the shared memory 3, and notifies the destination processor of information such as the write position.
  • the processor that has received the notification accesses the shared memory 3 to obtain the written data.
  • the present invention is not limited to the system having the shared memory as shown in FIG. 1, and can be applied to any multiprocessor system as long as it is a system capable of communicating between processors.
  • the present invention is directed to a multiprocessor system that processes a sequential execution program in which program units to be executed are stored in order.
  • the client processor requests the server processor to process in the form of a procedure call. This method is called remote manual call.
  • Asynchronous remote procedure call is a method that can continue other processing without waiting for the end of the process.
  • FIG. 2 illustrates parallel processing using asynchronous remote procedure calls.
  • the client processor instructs the server processor executing the procedure (program unit) with “start” to start the designated procedure, and waits for the completion of the procedure designated with “wait”.
  • server processor 1-1 has procedure (program unit) A
  • server processor 12 has procedure (program unit) B
  • server processor 1-3 has procedure (program unit) C
  • asynchronous remote procedure The client processor 1-0 on the procedure request side executes the procedure (program unit) D during the allocation and execution using the call. This allows four processes to be performed in parallel.
  • FIG. 3 illustrates this problem.
  • server processor 1-1 executes procedures A and C
  • server processor 1-2 executes procedures B and D.
  • the client processor 10 on the calling side of the procedure assumes that the procedure A is completed first, starts the procedures A and B, waits for the completion of the procedure A, starts the procedure C, and then starts the procedure B.
  • Procedure D is started after waiting for completion.
  • procedure B is completed first
  • procedure D cannot be started until procedure A is completed even if procedure B is completed.
  • the server processor 1 2 has a wasteful waiting time. Arise.
  • the client processor 1-0 on the procedure request side sequentially executes program units A, B, C, and D to be executed from the sequential execution program. Read to strike 5.
  • the client processor 1-0 has a procedure request program 6 for performing a process of assigning a procedure (program unit) read to the execution list 5 to a server processor.
  • the server processor 1-1, 1 2 on the procedure execution side has procedure call programs 7-1, 7-2 for performing processing to be called in order to execute the procedure (program unit).
  • the server processor 1-1 and 1 2 on the execution side of the procedure executes the execution queue 8-1 in the procedure call program 7-1 and 7-2 for executing the procedure specified by the client processor 10 on the procedure request side. 8—2 so that the procedure requesting client processor 1-0 can request the next procedure call without waiting for the previous procedure to be completed by queuing the procedure call request here. become. This solves the problem of waiting in turn and reduces wasted waiting time.
  • Patent Document 1 Japanese Patent Laid-Open No. 5-290003
  • Non-Patent Document 1 / 'Communication in the Mercury System "IEEE TH0212- 1/88/000 0/0178 $ 01.00
  • Non-Patent Document 2 "Asynchronous Remote Operation Execution in Distributed Systems” IEEE CH2878-7 / 90/0000/0253 $ 01.00
  • FIG. 4 waits for the completion of the procedure when a program unit that depends on the procedure as shown in FIG. 5 is assigned to a different processor. It is necessary, and a wasteful waiting time is generated due to the problem of waiting in turn.
  • Fig. 6 is a diagram explaining this problem, and shows the case where the program unit shown in Fig. 5 is executed.
  • the program unit shown in FIG. 5 is parallelized using asynchronous procedure calls.
  • procedure D is dependent only on procedure A, it can be queued to server processor 1-1.
  • procedure E has a dependency on procedures A and B, after procedure B is completed, it is necessary to wait for procedure A to complete and queue it to the power server processor 1-2.
  • Procedure F will complete Procedure B. Wait and then queue to server processor 1-3.
  • the order of waiting for completion of procedures A and B becomes a problem.
  • Fig. 6 it is assumed that procedure A is completed before procedure B, and waiting for procedure A to complete first. However, procedure B is actually completed first, so it is not necessary when procedure F is executed. Waiting time occurs.
  • An object of the present invention is to realize a multiprocessing method and a multiprocessor system capable of reducing useless waiting time due to turn waiting when executing a procedure (program unit) having the dependency relationship as described above. .
  • the execution order of a plurality of program units and the dependency relationships of the plurality of program units in the sequential execution program are registered, and the execution state of the plurality of program units is managed based on the registered dependency relationship. Then, the executable program unit is determined and assigned to the server processor in order.
  • the execution queue for queuing the call of a procedure is expanded so that the execution queue holds the procedure and its dependency relationship, and the dependency relationship that is held
  • the executable procedure is determined by referring to and executed.
  • the execution queue can be generated in the procedure request program of the client processor or in the procedure call program of the server processor.
  • the procedure call program of the server processor notifies the procedure request program of completion of the assigned procedure.
  • the procedure invocation program will complete the assigned procedure and any other client processor or other procedure that executes the dependent procedure. Notify the client processor.
  • a procedure execution status table that manages the execution status of multiple procedures (program units) is provided, and the procedure call program updates the procedure execution status table according to the completion of execution of the program unit, and further executes the procedure. It is also possible to determine an executable program unit by referring to the state table.
  • a multiprocessing method and a multiprocessor system Therefore, when executing a procedure (program unit) having a dependency relationship, it is possible to reduce unnecessary waiting time due to waiting in turn.
  • FIG. 1 is a diagram showing a schematic configuration of an example of a multiprocessor system targeted by the present invention.
  • FIG. 2 is a diagram showing parallel processing using asynchronous calls.
  • FIG. 3 is a diagram for explaining a problem of turn waiting in parallel processing.
  • FIG. 4 is a diagram showing a solution by queuing of the waiting problem in FIG.
  • FIG. 5 is a diagram showing a procedure (program unit) having a dependency relationship.
  • FIG. 6 is a diagram for explaining a problem in the conventional method.
  • FIG. 7 is a diagram showing parallel processing in the first embodiment of the present invention.
  • FIG. 8 is a flowchart showing a procedure request process after a procedure activation request (dispatch) in the parallel processing of the first embodiment.
  • FIG. 9 is a flowchart showing a procedure call process of the first embodiment.
  • FIG. 10 is a flowchart showing an end notification process on the procedure request side in the first embodiment.
  • FIG. 11 is a diagram showing parallel processing in the second embodiment of the present invention.
  • FIG. 12 is a flowchart showing a procedure request process after a procedure activation request (dispatch) in the parallel processing of the second embodiment.
  • FIG. 13 is a diagram showing parallel processing of the third exemplary embodiment of the present invention.
  • FIG. 14 is a flowchart showing a procedure request process after a procedure activation request (dispatch) in the parallel processing of the third embodiment.
  • FIG. 15 is a diagram showing parallel processing according to the fourth embodiment of the present invention.
  • FIG. 16 is a flowchart showing a procedure request process after a procedure activation request (dispatch) in the parallel processing of the fourth embodiment.
  • FIG. 17 is a flowchart showing procedure call processing in parallel processing of the fourth embodiment.
  • FIG. 18 is a flowchart showing an end notification process in the parallel processing of the fourth embodiment. It is.
  • FIG. 19 is a diagram showing parallel processing of the fifth exemplary embodiment of the present invention.
  • FIG. 20 is a flowchart showing a procedure request process after a procedure activation request (dispatch) in the parallel processing of the sixth embodiment of the present invention.
  • FIG. 21 is a flowchart showing procedure call processing in the parallel processing of the sixth embodiment.
  • FIG. 22 is a diagram showing parallel processing of the seventh exemplary embodiment of the present invention.
  • FIG. 23 is a flowchart showing a procedure request process after a procedure activation request (dispatch) in the parallel processing of the seventh embodiment.
  • FIG. 24 is a diagram showing parallel processing according to the eighth embodiment of the present invention.
  • FIG. 7 is a diagram for explaining parallel processing in the multiprocessor system of the first embodiment of the present invention.
  • the multiprocessor system of the first embodiment is, for example, any system that has a shared memory as shown in FIG. 1 as long as it is a multiprocessor system that executes a sequential execution program in a client-server system. But ...
  • the multiprocessor system of the first embodiment includes a client processor 10 and three server processors 1-1, 1, 2, and 13.
  • the server processor The number of wafers should be two or more.
  • the client processor 1-0 on the procedure request side executes program units (procedures) A, B, C, D, E, and F that also execute sequential execution program power. Read in Listing 5.
  • the sequential execution program also describes the dependency relations of procedures, and these are also read into the execution list 5 together.
  • the client processor 10 on the procedure request side has a procedure request program 6 for performing a process of assigning a procedure to the server processor.
  • the server processor 1—1, 1—2, 1—3 on the procedure execution side is a procedure call program 7—1, 7 that performs a process called to execute the procedure (program unit) specified by the client processor 1—0. — 2, 7— 3
  • the procedure request program 6 of the client processor 1-0 has one execution queue 8-0.
  • the procedure to be executed program 6 describes the procedure (program unit) to be executed and its dependencies in the execution list 5
  • the procedure request program 6 registers the information in the execution queue 80 and further adds a server processor for executing each procedure.
  • the information is determined and registered in the execution queue 80.
  • procedures A and D are executed by server processor 11
  • procedures B and E are executed by server processor 12
  • procedures C and F are executed by server processor 13, in addition to the procedures to be executed and their dependencies. To be registered.
  • the procedure request program 6 performs a process of assigning the procedure registered in the execution queue 8-0 to each server processor 1-1, 1-2, 1-3. Do.
  • FIG. 8 is a flowchart showing the processing of the procedure request program 6 after “dispatch” is issued (hereinafter, processing after dispatch).
  • FIG. 9 is a flowchart showing the processing of the procedure call programs 7-1, 7-2, 7-3 of the server processors 11, 1 2, 1 3 after the procedure activation request is issued from the procedure request program 6.
  • Figure 10 shows the procedure call program 7-1 7-2 and 7-3 are flowcharts showing the processing of the procedure request program 6 after receiving notification of procedure completion.
  • the procedure request program 6 searches for an executable procedure from the execution queue 8-0 in step 101.
  • step 102 it is determined whether there is an executable procedure. Once completed, other processing not described here can be performed.
  • step 103 it is determined whether the target server processor that is prescribed to execute the executable procedure in the execution queue 8-0 is executing the procedure. If it is being executed, the process returns to step 101. If it is not being executed, the process proceeds to step 104 to instruct the target server provider to start the procedure.
  • step 105 the status of the target server processor is changed during execution, and the process returns to step 101.
  • the target server processor 11 is not being executed, so the server processor 1-1 is instructed to start the procedure A.
  • the server processor 1-2 is instructed to start the procedure B, and the server processor 13 is instructed to start the procedure C.
  • step 103 After instructing the start of procedure C, all three server processors are executing the procedure, so the determination in step 103 is Yes, and after returning to step 101, the procedure can be executed in step 102. Because it is determined that there is no proper procedure, the process ends. As will be described later, the client processor 10 receives an end notification as an interrupt, and thus performs other processes until then.
  • the procedure call programs 7-1, 7-2, and 7-3 perform the processing of FIG.
  • the procedure start request is received
  • the requested procedure is started in step 111 and the procedure is executed in step 112.
  • the procedure completion is notified to the procedure request program 6 of the client processor 10 on the procedure request side in step 113. Then wait for the next activation request.
  • the procedure request program 6 When the procedure request program 6 receives a notification of procedure call program procedure completion by interrupt processing, the procedure request program 6 is executed to change the completed procedure from the execution state to the completion in step 121 as shown in FIG. Queue 8—Updates 0. Then, in step 122, the state of the server processor that executed the procedure is changed to completion, that is, free. In step 123, the “dispatch” process of FIG. 8 is performed. If the "dispatch" process in Fig. 8 ends Returns to the state before the interrupt.
  • the procedure request program 6 loops between steps 101 and 103 after instructing an activation request for the procedures A, B, and C.
  • the processing of procedure B of server processor 12 is completed first, the completion notification is received, and the processing of FIG. 10 is performed. Since remaining procedure D depends on procedure A, procedure E depends on procedures A and B, and procedure F depends on procedures B and C, it is determined that there is no procedure that can be executed in step 102 in FIG. Is done.
  • the processing of the procedure C of the server processor 13 is completed and a completion notification is received.
  • the processing of FIG. 10 is performed, so that the procedure F can be executed and the server processor 13 becomes empty. Therefore, the server processor 13 is requested to start the procedure F.
  • the procedure D and ⁇ can be executed in the same manner, the server processor 1 1 becomes free, and the server processor 1 2 Since it is already empty, the server processor 11 is requested to start procedure D and the server processor 12 is requested to start procedure E.
  • step 102 in Fig. 8 it is determined in step 102 in Fig. 8 that there is no executable procedure, and the procedure is terminated. Thereafter, when the procedures D, E, and F are completed, the processing in FIG. 10 is similarly performed, and the procedure is terminated because there is no procedure to be executed.
  • the server processor 13 has a wasteful waiting time WT until the procedure F is started after the procedure C is completed.
  • procedure F is started immediately after procedure C is completed.
  • FIG. 11 is a diagram for explaining parallel processing in the multiprocessor system according to the second embodiment of the present invention.
  • the server queue that executes each procedure is not defined in the execution queue 80 of the procedure request program 6, and the server processor that executes each procedure dynamically changes according to the processing status.
  • the other points are the same as in the first embodiment.
  • the procedure request program 6 performs the post-dispatch processing of FIG. 12 instead of the processing of FIG.
  • Steps 131 and 132 are performed. If it is determined in step 132 that there is an executable procedure, step 133 is searched for an executable server processor. In step 134, it is determined whether there is an executable server processor. Go to step 135. Steps 135 and 136 are the same as steps 104 and 105 in the first embodiment.
  • the procedure F can be executed, and the server processors 12 and 13 are in an empty state. Start procedure F for.
  • FIG. 13 is a diagram for explaining parallel processing in the multiprocessor system of the third embodiment of the present invention.
  • the procedure request program 6 has three execution queues 8—0—1, 8 ⁇ 0-2, 8 ⁇ 0-3 corresponding to three server processors. Unlike the first embodiment, the others are the same as the first embodiment.
  • the procedure request program 6 performs post-dispatch processing in FIG. 14 instead of the processing in FIG.
  • an executable server processor that is, a free server processor is searched in step 144.
  • step 142 it is determined whether there is an executable server processor. If there is no server processor that can be executed, no new procedure can be started. If there is an executable server processor, in step 143, the execution queue 8—0—1, 8 -0- 2, 8 0 3 of the execution queue corresponding to the server processor is searched for an executable procedure.
  • step 144 it is determined whether there is an executable procedure. If there is no executable procedure, the process returns to step 141. Steps 145 and 146 are the same as steps 104 and 105 in the first embodiment.
  • FIG. 15 is a diagram for explaining parallel processing in the multiprocessor system according to the fourth embodiment of the present invention.
  • the server processor manual call programs 7-1, 7-2 and 7-3 have execution queues 8-1, 8-2 and 8-3, respectively. Unlike the embodiment, the rest is the same.
  • the procedure request program 6 of the client processor 1-0 has an execution queue 80 in which a procedure to be executed and a server processor for executing the procedure are described, and manages the overall execution state.
  • a sequential execution program which server for each procedure (program unit) If the execution list 5 describes the procedure to be executed, the server processor to be executed, and the dependencies, the procedure request program 6 of the client processor 10 is sent to the corresponding server processor. Notify information. In response to this, each server processor registers the procedure to be executed and the dependency relationship in each execution queue.
  • FIG. 16 is a diagram illustrating post-dispatch processing in the fourth embodiment.
  • the procedure request program 6 of the client processor 1-0 receives “dispatch”, it notifies all server processors 1-1, 12 and 1-3 of “dispatch”.
  • FIG. 17 is a diagram showing processing of the procedure call program of the server processor after receiving the “dispatch” notification.
  • each procedure calling program After receiving the “dispatch” notification, each procedure calling program searches for an executable procedure from each execution queue at step 161 and determines whether there is an executable procedure at step 162. If there is an executable procedure, go to step 163 to execute the procedure.
  • step 164 all server processors 1-1, 1-2, 1-3 are notified of completion, and in step 165, the execution state of the procedure in the execution queue is changed to complete. Update and return to step 161.
  • step 162 If it is determined in step 162 that there is no executable procedure, it is determined in step 166 whether or not there are procedures to be executed in the execution queue. Return. If not, the process proceeds to Step 167 to notify the procedure request program 6 of the client processor 1-0 that the activation is requested, that is, the assigned procedure is completed, and waits for the next dispatch.
  • FIG. 18 is a diagram showing processing when the procedure request program 6 of the client processor 10 is notified that the procedure is completed from the procedure call program of the server processor.
  • the completion notification is received, in step 171, the execution state is updated to completion for the procedure completed in the execution queue 8-0.
  • FIG. 19 is a diagram for explaining parallel processing in the multiprocessor system according to the fifth embodiment of the present invention.
  • the multiprocessor system of the fifth embodiment is affected by the result of the procedure to be executed in the execution queues 8-1, 8, 2 and 8-3 of the procedure call programs 7-1, 1, 2-2 and 7-3.
  • the procedure executed by other server processors is different from the fourth embodiment in that information on other server processors is registered. [0050] Since the procedure affected by the result of the executed procedure and executed by another server processor is known, the completion of execution may be notified to the server processor.
  • the multiprocessor system of the first embodiment it is also possible to perform this by polling, which has received the notification of completion of the procedure from the server processor by interruption.
  • the multiprocessor system of the sixth embodiment of the present invention is the same as the multiprocessor system of the first embodiment except that the completion notification of the procedure is received by polling.
  • the procedure request program of the client processor performs the post-dispatch processing of FIG. 20, and the procedure call program of the server processor The procedure call processing shown in Fig. 21 is performed.
  • the post-dispatch processing in FIG. 20 searches for an executable procedure from the execution queue 8-0 in step 181 after receiving “dispatch”.
  • Step 182 determines if there are any executable procedures. If there is an executable procedure, step 183 determines whether the target server processor is executing the procedure. If it is being executed, the process returns to step 181. If it is not being executed, the process proceeds to step 184 to instruct the target server processor to start the procedure. In step 185, the state of the target server processor is changed during execution, and the process returns to step 181.
  • step 182 When it is determined in step 182 that there is no executable procedure, in step 186, the execution statuses of all server processors 1-1, 1-2, 1-3 are investigated. It is then determined whether there is a server processor that has completed the procedure. If not, return to step 186 and repeat steps 186 and 187 until any server processor completes the procedure.
  • step 188 it changes the wait state of the execution queue 8-0
  • step 189 it changes its server processor state to finished, and in step 190 all registered Determine whether the procedure has been completed. If it is completed, the process ends. If it is not completed, the process returns to step 181.
  • step 203 the process waits until a completion confirmation request is received from the procedure request program 6 of the client processor 10.
  • the completion is notified and the next activation request is awaited.
  • FIG. 22 is a diagram for explaining parallel processing in the multiprocessor system according to the seventh embodiment of the present invention.
  • processors that do not notify completion by interruption to other server processors after completion of the procedure as in the fourth embodiment are mutually read and written to the shared memory 3. It differs from the fourth embodiment in that it has a possible area and an execution state table 9 in which the execution state of the procedure is described is provided in that area.
  • Each server processor updates the execution state table 9 when the assigned procedure is complete.
  • Each server processor can know which procedure has been completed by referring to the execution state table 9.
  • the execution state table 9 situation is prepared by the procedure request program 6 of the client processor 1-0.
  • the procedure request program 6 completes the procedure when it creates the execution queues 8-1, 8-2, 8-3 by registering the procedures in the procedure call programs 7-1, 7-2, 7-3. Specifies the location of the execution state table 9 that is sometimes updated. Therefore, the procedure request program 6 executes the post-dispatch processing shown in FIG.
  • the procedure call program executes a procedure call process shown in FIG.
  • the procedure call process in FIG. 23 is similar to the process in FIG. 17 and is a process in which step 164 is deleted in the process in FIG.
  • FIG. 24 is a diagram for explaining parallel processing in the multiprocessor system according to the eighth embodiment of the present invention.
  • the dependency is also described in the sequential execution program.
  • the execution list 5 is created, the dependency is also included, and when the procedure to be executed is registered in the execution queue 80, Unlike the first embodiment, the dependency relationship is automatically registered together, and the rest is the same as the first embodiment. Therefore, there is no need to wait until the dependency is registered. “Dispatch” is not necessary.
  • the same processing as “dispatch” is performed.
  • This processing method can also be applied to the second to fifth embodiments. Needless to say, various modifications of the force described in the embodiments of the present invention are possible.

Abstract

　依存関係のある手続（プログラムユニット）を実行する場合に、順番待ちによる無駄な待ち時間を削減できるマルチプロセッシング方法及びマルチプロセッサシステムが記載されており、逐次実行プログラムにおける複数のプログラムユニットの実行順及び複数のプログラムユニットの依存関係を登録し、登録した依存関係に基づいて複数のプログラムユニットの実行状態を管理し、実行可能なプログラムユニットを判定して、順次サーバプロセッサに割当てて実行する。

Description

明 細 書
マルチプロセッシング方法及びマルチプロセッサシステム 技術分野
[0001] 本発明は、マルチプロセッシング方法及びマルチプロセッサシステムに関し、特に クライアントプロセッサ力 逐次実行プログラムに順に記憶された複数のプログラムュ ニットを、サーバプロセッサに割当てることにより、実行するマルチプロセッシング方法 及びマノレチプロセッサシステムに関する。
背景技術
[0002] 複数のプロセッサを通信経路で相互に接続し、処理を分担して実行するマルチプ 口セッサシステムが知られている。マルチプロセッサシステムには、各プロセッサが対 等であるシステムと、プロセッサの 1つがクライアントプロセッサ（マシン）で、他のプロ セッサがサーバプロセッサ（マシン）で、クライアントプロセッサが各サーバプロセッサ に処理を割当て、その結果をまとめる処理を行うクライアント ·サーバ方式のシステム とがある。本発明は、クライアント 'サーバ方式のマルチプロセッサシステムに関する。
[0003] マルチプロセッサシステムにおけるプロセッサ間の通信方式として各種の方式が提 案されている力 代表的なものに共有メモリ方式がある。図 1は、共有メモリ方式のマ ルチプロセッサシステムの概略構成を示す図である。図 1に示すように、このシステム は、共有バス 2と、供給バス 2に接続される複数のプロセッサ 1— 0、 1— 1、 1— 2、… 、 1—N及び共有メモリ 3とを有する。データを送信する時には、各プロセッサは、送 信するデータを共有メモリ 3に書き込み、書き込み位置などの情報を送信先のプロセ ッサに通知する。通知を受けたプロセッサは共有メモリ 3にアクセスして書き込まれた データを得る。本発明は、図 1に示したような共有メモリを有する方式に限定されず、 プロセッサ間で通信を行えるシステムであればどのようなマルチプロセッサシステムに も適用可能である。
[0004] また、マルチプロセッサシステムで実行するプログラムの形式も各種ある力 本発明 は、実行するプログラムユニットを順に記憶した逐次実行プログラムを処理するマル チプロセッサシステムを対象とする。 [0005] クライアント 'サーバ方式のマルチプロセッサシステムでは、クライアントプロセッサか らサーバプロセッサに対して手続呼出の形式で処理を依頼する。この手法を遠隔手 続呼出と称する。
[0006] 遠隔手続呼出では、クライアントプロセッサは、サーバプロセッサに処理を依頼した 後、サーバプロセッサでの処理が終了し、それが通知されるまで待つ必要があるが、 クライアントプロセッサがサーバプロセッサでの処理の終了を待たずに他の処理を ϋ 続できる方法として非同期の遠隔手続呼出がある。
[0007] マルチプロセッサシステムでは、この非同期の遠隔手続呼出を利用して、クライアン トプロセッサ力 複数のサーバプロセッサに対して非同期の遠隔手続呼出を行うこと により並列処理を行う。図 2は、非同期の遠隔手続呼出を使った並列処理を説明す る図である。ここで、クライアントプロセッサは、 "start"で手続（プログラムユニット）を 実行する側のサーバプロセッサに対して指定された手続の起動を指示し、 "wait"で 指定した手続の完了を待つ。図 2では、サーバプロセッサ 1—1に手続 (プログラムュ ニット） Aを、サーバプロセッサ 1 2に手続（プログラムユニット） Bを、サーバプロセッ サ 1—3に手続 (プログラムユニット) Cを、非同期の遠隔手続呼出を利用して割当て て実行させ、この間に手続要求側のクライアントプロセッサ 1—0は、手続 (プログラム ユニット) Dを実行する。これにより、 4つの処理を並列に行うことができる。
[0008] 非同期の遠隔手続呼出を利用して並列処理を行った場合に問題になるのが、順番 待ちの問題である。図 3はこの問題を説明する図である。図 3では、サーバプロセッサ 1— 1で手続 Aと Cを、サーバプロセッサ 1—2で手続 Bと Dを実行する。この際、手続 呼出側のクライアントプロセッサ 1 0では、手続 Aが先に完了すると想定して手続 A と Bを起動した後、先に手続 Aの完了を待って手続 Cを起動し、その後手続 Bの完了 を待って手続 Dを起動する。しかし、実際に実行したところ、手続 Bが先に完了した場 合、手続 Bが完了しても手続 Aが完了するまで手続 Dを起動できず、この間サーバプ 口セッサ 1 2に無駄な待ち時間が生じる。
[0009] 上記のような問題を解決するために、図 4に示すようなキューイングによる解決法が 考えられている。図 4に示した構成によれば、手続要求側のクライアントプロセッサ 1 — 0は、逐次実行プログラムから実行するプログラムユニット A、 B、 C、 Dを順次実行リ スト 5に読み出す。クライアントプロセッサ 1—0は、実行リスト 5に読み出された手続（ プログラムユニット）をサーバプロセッサに割当てる処理を行う手続要求プログラム 6を 有する。手続実行側のサーバプロセッサ 1— 1、 1 2は、手続 (プログラムユニット）を 実行するために呼び出す処理を行う手続呼出プログラム 7—1、 7— 2を有する。手続 実行側のサーバプロセッサ 1— 1、 1 2は、手続要求側のクライアントプロセッサ 1 0から指定された手続を実行するための手続呼出プログラム 7—1、 7— 2内に実行キ ユー 8— 1、 8— 2を有するため、ここで手続呼出の要求をキューイングすることで、手 続要求側のクライアントプロセッサ 1—0は先行の手続の完了を待たずに次の手続の 呼出を要求できるようになる。これにより、順番待ちの問題が解消され、無駄な待ち時 間を削減できる。
[0010] 特許文献 1 :特開平 5— 290003号公報
非特許文献 1 /'Communication in the Mercury System" IEEE TH0212- 1/88/000 0/0178$01.00
非特許文献 2： "Asynchronous Remote Operation Execution in Distributed Syste ms" IEEE CH2878-7/90/0000/0253$01.00
発明の開示
発明が解決しょうとする課題
[0011] し力しながら、図 4に示すように単純にキューイングしただけでは、図 5に示したよう な手続間で依存があるプログラムユニットを異なるプロセッサに割当てた場合、手続 の完了を待つ必要があり、順番待ちの問題により無駄な待ち時間が発生する。図 6 は、この問題を説明する図であり、図 5に示したプログラムユニットを実行する場合を 示す。
[0012] 図 6では、図 5に示したプログラムユニットを非同期の手続呼出を利用して並列化し ている。ここで、手続 A、 B、 Cの間には依存関係がないため、 3つのサーバプロセッ サ 1 1〜 1 3で並列に実行することが可能である。手続 Dは手続 Aのみに依存関 係があるため、サーバプロセッサ 1—1にキューイングすればよい。手続 Eは手続 Aと Bに依存関係があるため、手続 Bが完了した後さらに手続 Aの完了を待って力 サー バプロセッサ 1—2にキューイングする必要がある。同様に、手続 Fは手続 Bの完了を 待ってからサーバプロセッサ 1—3にキューイングする。ここで、手続 Aと Bの完了待ち の順番が問題になる。図 6では、手続 Aが手続 Bよりも先に完了すると仮定して先に 手続 Aの完了を待っているが、実際には手続 Bが先に完了してしまったため、手続 F の実行時に無駄な待ち時間が発生する。
[0013] 本発明は、上記のような依存関係のある手続 (プログラムユニット）を実行する場合 に、順番待ちによる無駄な待ち時間を削減できるマルチプロセッシング方法及びマ ルチプロセッサシステムの実現を目的とする。 課題を解決するための手段
[0014] 本発明によれば、逐次実行プログラムにおける複数のプログラムユニットの実行順 及び複数のプログラムユニットの依存関係を登録し、登録した依存関係に基づ 、て 複数のプログラムユニットの実行状態を管理し、実行可能なプログラムユニットを判定 して、順次サーバプロセッサに割当てて実行する。
[0015] 具体的には、手続 (プログラムユニット）の呼出をキューイングしておく実行キューを 拡張して、実行キューが手続とその手続に対する依存関係を保持するようにし、保持 している依存関係を参照して実行可能な手続を判定して実行する。
[0016] 実行キューは、クライアントプロセッサの手続要求プログラム内に生成することも、サ ーバプロセッサの手続呼出プログラム内に生成することもできる。
[0017] クライアントプロセッサの手続要求プログラムが実行キューを有する場合には、サー バプロセッサの手続呼出プログラムは、割当てられた手続の完了を手続要求プロダラ ムに通知する。
[0018] サーバプロセッサの手続呼出プログラムが実行キューを有する場合には、手続呼 出プログラムは、割当てられた手続の完了を、他のすべてのクライアントプロセッサ又 は依存関係のある手続を実行する他のクライアントプロセッサに通知する。なお、複 数の手続 (プログラムユニット）の実行状態を管理する手続実行状態テーブルを設け て、手続呼出プログラムは、プログラムユニットの実行完了に応じて手続実行状態テ 一ブルを更新し、さらに手続実行状態テーブルを参照して実行可能なプログラムュ ニットを判定することも可能である。
[0019] 本発明によれば、マルチプロセッシング方法及びマルチプロセッサシステムにおい て、依存関係のある手続 (プログラムユニット）を実行する場合に、順番待ちによる無 駄な待ち時間を削減できる。
図面の簡単な説明
[図 1]図 1は、本発明が対象とするマルチプロセッサシステムの一例の概略構成を示 す図である。
[図 2]図 2は、非同期呼出を使った並列処理を示す図である。
[図 3]図 3は、並列処理における順番待ちの問題を説明する図である。
[図 4]図 4は、図 3の順番待ちの問題のキューイングによる解決法を示す図である。
[図 5]図 5は、依存関係のある手続 (プログラムユニット）を示す図である。
[図 6]図 6は、従来手法での問題を説明する図である。
[図 7]図 7は、本発明の第 1実施例の並列処理を示す図である。
[図 8]図 8は、第 1実施例の並列処理における手続起動要求（dispatch)後の手続要求 処理を示すフローチャートである。
[図 9]図 9は、第 1実施例の手続呼出処理を示すフローチャートである。
[図 10]図 10は、第 1実施例の手続要求側の終了通知処理を示すフローチャートであ る。
[図 11]図 11は、本発明の第 2実施例の並列処理を示す図である。
[図 12]図 12は、第 2実施例の並列処理における手続起動要求（dispatch)後の手続 要求処理を示すフローチャートである。
[図 13]図 13は、本発明の第 3実施例の並列処理を示す図である。
[図 14]図 14は、第 3実施例の並列処理における手続起動要求（dispatch)後の手続 要求処理を示すフローチャートである。
[図 15]図 15は、本発明の第 4実施例の並列処理を示す図である。
[図 16]図 16は、第 4実施例の並列処理における手続起動要求（dispatch)後の手続 要求処理を示すフローチャートである。
[図 17]図 17は、第 4実施例の並列処理における手続呼出処理を示すフローチャート である。
[図 18]図 18は、第 4実施例の並列処理における終了通知処理を示すフローチャート である。
[図 19]図 19は、本発明の第 5実施例の並列処理を示す図である。
[図 20]図 20は、本発明の第 6実施例の並列処理における手続起動要求（dispatch) 後の手続要求処理を示すフローチャートである。
[図 21]図 21は、第 6実施例の並列処理における手続呼出処理を示すフローチャート である。
[図 22]図 22は、本発明の第 7実施例の並列処理を示す図である。
[図 23]図 23は、第 7実施例の並列処理における手続起動要求（dispatch)後の手続 要求処理を示すフローチャートである。
[図 24]図 24は、本発明の第 8実施例の並列処理を示す図である。
符号の説明
[0021] 1 -0 クライアントプロセッサ
1 1、 1 2、 1 3、 1 n サーバプロセッサ
6 手続要求プログラム
7— 1、 7— 2、 7— 3 手続呼出プログラム
8— 0、 8— 1、 8— 2、 8— 3 実行キュー
発明を実施するための最良の形態
[0022] 以下、本発明の実施例を説明する。以下の実施例では、図 5のプログラムユニットを 有する逐次実行プログラムを、図 6の 1個のクライアントプロセッサと 3個のサーバプロ セッサで構成されるマルチプロセッサシステムで実行するものとする。
[0023] 図 7は、本発明の第 1実施例のマルチプロセッサシステムにおける並列処理を説明 する図である。第 1実施例のマルチプロセッサシステムは、例えば、図 1に示すような 共有メモリを有するシステムである力 クライアント 'サーバ方式で、逐次実行プロダラ ムを実行するマルチプロセッサシステムであれば、どのようなシステムでもよ 、。
[0024] 図 7に示すように、第 1実施例のマルチプロセッサシステムは、クライアントプロセッ サ 1 0と、 3個のサーバプロセッサ 1— 1、 1 2、 1 3と、を備えるが、サーバプロセ ッサの個数は 2個以上であればよい。手続要求側のクライアントプロセッサ 1—0は、 逐次実行プログラム力も実行するプログラムユニット（手続) A、 B、 C、 D、 E、 Fを実行 リスト 5に読み出す。逐次実行プログラムには、手続の依存関係も記載されており、そ れらも合わせて実行リスト 5に読み出す。
[0025] 手続要求側のクライアントプロセッサ 1 0は、サーバプロセッサに手続を割当てる 処理を行う手続要求プログラム 6を有する。手続実行側のサーバプロセッサ 1— 1、 1 —2、 1—3は、クライアントプロセッサ 1—0から指定された手続 (プログラムユニット） を実行するために呼び出す処理を行う手続呼出プログラム 7— 1、 7— 2、 7— 3を有 する。
[0026] 実行リスト 5では、実行する手続を順番に読み出じ' start"が付加され、依存関係が ある場合には、その後に "dep"で依存関係を記載する。図示の例では、手続 A、 B、 Cは依存関係はないが、手続 Dは手続 Aの処理結果を使用する依存関係があり、手 続 Eは手続 Aと Bの処理結果を使用する依存関係があり、手続 Fは手続 Bと Cの処理 結果を使用する依存関係がある。実行リスト 5の作成が完了すると、 "dispatch"で実 行開始を指示する。従来は、 "start"で手続の記載を行うと、直ちに実行開始が指示 されたが、本実施例では、手続を記載しただけでは依存関係が記載されないため、 " start"及び" dep"の記載がすべて完了した後、 "dispatch"で実行開始を指示する。
[0027] クライアントプロセッサ 1—0の手続要求プログラム 6は、 1つの実行キュー 8— 0を有 する。手続要求プログラム 6は、実行リスト 5に、実行する手続 (プログラムユニット)及 びその依存関係が記載されると、実行キュー 8 0にそれらの情報を登録すると共に 、さらに各手続を実行するサーバプロセッサを決定して、それらの情報を実行キュー 8 0に登録する。図示の例では、実行する手続、その依存関係に加えて、手続 A及 び Dはサーバプロセッサ 1 1で、手続 Bと Eはサーバプロセッサ 1 2で、手続 Cと F はサーバプロセッサ 1 3で実行されることが登録される。
[0028] 手続要求プログラム 6は、実行リスト 5に" dispatch"が入ると、実行キュー 8— 0も登 録された手続を各サーバプロセッサ 1— 1、 1— 2、 1—3に割当てる処理を行う。
[0029] 図 8は、 "dispatch"が出された後の手続要求プログラム 6の処理（以下 dispatch後 処理）を示すフローチャートである。また、図 9は手続要求プログラム 6から手続起動 要求がされた後のサーバプロセッサ 1 1、 1 2、 1 3の手続呼出プログラム 7— 1 、 7— 2、 7— 3の処理を示すフローチャートであり、図 10は手続呼出プログラム 7—1 、 7— 2、 7— 3から手続完了の通知を受けた後の手続要求プログラム 6の処理を示す フローチャートである。
[0030] 手続要求プログラム 6は、ステップ 101で、実行キュー 8— 0から実行可能な手続を 探す。ステップ 102で、実行可能な手続が無いかを判定し、無ければ終了する。終了 した後は、ここに記載していない他の処理を行うことができる。実行可能な手続がある 時には、ステップ 103で、実行キュー 8— 0において実行可能な手続を行うことが規定 されている対象サーバプロセッサが手続を実行中であるかを判定する。実行中であ れば、ステップ 101に戻り、実行中でなければ、ステップ 104に進み、対象サーバプ 口セッサにその手続の起動を指示する。そして、ステップ 105で、対象サーバプロセッ サの状態を実行中に変更してステップ 101に戻る。
[0031] 最初の手続 Aであれば、対象サーバプロセッサ 1 1は実行中でないので、サーバ プロセッサ 1—1に手続 Aの起動を指示する。以下、サーバプロセッサ 1—2に手続 B の起動を、サーバプロセッサ 1 3に手続 Cの起動を指示する。
[0032] 手続 Cの起動指示を行った後は、 3つのサーバプロセッサはすべて手続を実行中 であるので、ステップ 103での判定が Yesとなり、ステップ 101に戻った後、ステップ 1 02で実行可能な手続無し、と判定されるので、終了する。クライアントプロセッサ 1 0は、後述するように終了通知を割り込みで受けるので、それまで他の処理を行う。
[0033] 一方、手続起動要求を受けたサーバプロセッサ 1 1、 1 2、 1 3は、その手続呼 出プログラム 7—1、 7— 2、 7— 3がそれぞれ図 9の処理を行う。手続起動要求を受け ると、ステップ 111で、要求された手続を起動し、ステップ 112で手続を実行する。手 続の完了を待ち、手続が完了すると、ステップ 113で手続要求側のクライアントプロセ ッサ 1 0の手続要求プログラム 6に手続完了を通知する。そして、次の起動要求が 来るのを待つ。
[0034] 手続要求プログラム 6は、手続呼出プログラム力 手続完了の通知を割込み処理に より受けると、図 10に示すように、ステップ 121で、完了した手続を実行状態から完了 に変更するように実行キュー 8— 0を更新する。そして、ステップ 122で、その手続を 実行したサーバプロセッサの状態を実行完了、すなわち空き状態に変更する。ステツ プ 123では、図 8の" dispatch"処理を行う。もし、図 8の" dispatch"処理が終了する と、割り込み前の状態に復帰する。
[0035] 図 7及び図 8に戻ると、手続要求プログラム 6は、手続 A、 B、 Cの起動要求を指示し た後、ステップ 101と 103の間をループしている。 3つの手続のうち、最初にサーバプ 口セッサ 1 2の手続 Bの処理が完了して、完了通知を受け、図 10の処理を行う。残 つている手続 Dは手続 Aに依存し、手続 Eは手続 A、 Bに依存し、手続 Fは手続 B、 C に依存しているので、図 8のステップ 102では実行できる手続はないと判定される。次 に、サーバプロセッサ 1 3の手続 Cの処理が完了して、完了通知を受ける。同様に 図 10の処理を行い、手続 Fが実行可能になり、サーバプロセッサ 1 3が空き状態に なるので、サーバプロセッサ 1 3に対して手続 Fの起動要求を行う。さらに、サーバ プロセッサ 1 1の手続 Aの処理が完了して、完了通知を受けると、同様に手続 D及 ひ Έが実行可能になり、サーバプロセッサ 1 1が空き状態になり、サーバプロセッサ 1 2は既に空き状態であるので、サーバプロセッサ 1 1に対して手続 Dの起動要 求を、サーバプロセッサ 1 2に対して手続 Eの起動要求を行う。
[0036] 手続 D及び Eの起動要求を行うと、実行する手続が残っていないので、図 8のステツ プ 102で、実行可能な手続は無い、と判定されるので、終了する。以下、手続 D、 E、 Fの処理が完了すると、同様に図 10の処理を行い、実行する手続が残っていないの で終了する。
[0037] 図 6と図 7を比較して明らかなように、従来例では、サーバプロセッサ 1 3において 、手続 Cが完了した後、手続 Fを起動するまで無駄な待ち時間 WTがあったが、第 1 実施例では、手続 Cが完了した後、手続 Fが直ぐに起動されている。
[0038] 図 11は、本発明の第 2実施例のマルチプロセッサシステムにおける並列処理を説 明する図である。第 2実施例のマルチプロセッサシステムは、手続要求プログラム 6の 実行キュー 8 0で、各手続を実行するサーバプロセッサが規定されておらず、処理 状況に応じて各手続を実行するサーバプロセッサが動的に決定される点が、第 1実 施例と異なり、他は第 1実施例と同じである。各手続を実行するサーバプロセッサを 動的に決定するため、手続要求プログラム 6が、図 8の処理の代わりに、図 12の disp atch後処理を行う。
[0039] 図 12の第 2実施例の dispatch後処理は、第 1実施例のステップ 101及び 102と同 じステップ 131及び 132を行う。ステップ 132で、実行可能な手続があると判定される と、ステップ 133で、実行可能なサーバプロセッサを探し、ステップ 134で、実行可能 なサーバプロセッサが無いかを判定し、無ければ終了し、あればステップ 135に進む 。ステップ 135及び 136は、第 1実施例のステップ 104及び 105と同じである。
[0040] 図 11に示すように、第 2実施例では、手続 Bと Cが完了すると、手続 Fが実行可能で あり、サーバプロセッサ 1 2と 1 3が空き状態にあるので、サーバプロセッサ 1 2 に対して手続 Fを起動する。
[0041] 図 13は、本発明の第 3実施例のマルチプロセッサシステムにおける並列処理を説 明する図である。第 3実施例のマルチプロセッサシステムは、手続要求プログラム 6が 、 3個のサーバプロセッサに対応して 3個の実行キュー 8— 0—1、 8 -0- 2, 8 -0- 3を有する点が第 1実施例と異なり、他は第 1実施例と同じである。手続要求プロダラ ム 6は、図 8の処理の代わりに、図 14の dispatch後処理を行う。
[0042] 図 14の第 3実施例の dispatch後処理によれば、 "dispatch"を受けると、ステップ 1 41で、実行可能なサーバプロセッサ、すなわち空き状態のサーバプロセッサを探す 。ステップ 142で、実行可能なサーバプロセッサが無いかを判定する。実行可能なサ ーバプロセッサが無ければ、新たに手続の起動は行えないので、終了する。実行可 能なサーバプロセッサがあれば、ステップ 143で、実行キュー 8— 0—1、 8 -0- 2, 8 0 3のうちそのサーバプロセッサに対応する実行キュー力 実行可能な手続を探 す。ステップ 144で、実行可能な手続が無いか判定し、無ければステップ 141に戻り 、あればステップ 145に進む。ステップ 145及び 146は、第 1実施例のステップ 104 及び 105と同じである。
[0043] 図 15は、本発明の第 4実施例のマルチプロセッサシステムにおける並列処理を説 明する図である。第 4実施例のマルチプロセッサシステムは、サーバプロセッサの手 続呼出プログラム 7—1、 7— 2、 7— 3がそれぞれ実行キュー 8— 1、 8— 2、 8— 3を有 する点が第 1実施例と異なり、他は同じである。なお、クライアントプロセッサ 1—0の 手続要求プログラム 6は、実行する手続及びそれを実行するサーバプロセッサを記 載した実行キュー 8 0を有し、全体の実行状態を管理する。
[0044] この実施例では、逐次実行プログラムに、各手続 (プログラムユニット）にどのサーバ プロセッサで実行するかが規定されており、実行リスト 5に実行する手続、実行するサ ーバプロセッサ及び依存関係が記載されると、クライアントプロセッサ 1 0の手続要 求プログラム 6は、対応するサーバプロセッサにその情報を通知する。これに応じて、 各サーバプロセッサは、実行する手続及び依存関係を各実行キューに登録する。
[0045] 図 16は、第 4実施例の dispatch後処理を示す図である。クライアントプロセッサ 1— 0の手続要求プログラム 6は、 "dispatch"を受けると、すべてのサーバプロセッサ 1— 1、 1 2、 1—3に" dispatch"を通知する。
[0046] 図 17は、 "dispatch"通知を受けた後のサーバプロセッサの手続呼出プログラムの 処理を示す図である。各手続呼出プログラムは、 "dispatch"通知を受けた後、ステツ プ 161で、各実行キューから実行可能な手続を探し、ステップ 162で、実行可能な手 続が無いか判定する。実行可能な手続があれば、ステップ 163に進んで手続を実行 する。そして、手続の実行が完了すると、ステップ 164で、すべてのサーバプロセッサ 1— 1、 1— 2、 1—3に完了を通知し、ステップ 165で、実行キューの手続の実行状態 を完了に変更して更新し、ステップ 161に戻る。
[0047] ステップ 162で、実行可能な手続が無 、と判定された場合には、ステップ 166で、 実行キューに実行する手続が残って 、るかを判定し、残って 、ればステップ 161に 戻る。残っていなければ、ステップ 167に進んで、クライアントプロセッサ 1—0の手続 要求プログラム 6に起動の要求された、すなわち割当てられた手続が完了したことを 通知し、次の dispatchを待つ状態になる。
[0048] 図 18は、クライアントプロセッサ 1 0の手続要求プログラム 6が、サーバプロセッサ の手続呼出プログラムから手続が完了したことを通知された時の処理を示す図である 。完了通知を受けると、ステップ 171で、実行キュー 8— 0において完了した手続に対 して実行状態を完了に更新する。
[0049] 図 19は、本発明の第 5実施例のマルチプロセッサシステムにおける並列処理を説 明する図である。第 5実施例のマルチプロセッサシステムは、手続呼出プログラム 7— 1、 7— 2、 7— 3の実行キュー 8— 1、 8— 2、 8— 3に、実行する手続の結果に影響さ れ且つ他のサーバプロセッサで実行される手続につ!、ては、他のサーバプロセッサ の情報を登録する点が第 4実施例と異なり、他は同じである。 [0050] 実行した手続の結果に影響され且つ他のサーバプロセッサで実行される手続が分 かるので、そのサーバプロセッサに実行の完了を通知すればよい。
[0051] 第 1実施例のマルチプロセッサシステムでは、サーバプロセッサからの手続の完了 通知を割り込みで受信していた力 これをポーリングで行うことも可能である。本発明 の第 6実施例のマルチプロセッサシステムは、第 1実施例のマルチプロセッサシステ ムにおいて、手続の完了通知の受信をポーリングで行うようにした点が異なり、他は 同じである。
[0052] 手続の完了通知の受信をポーリングで行うために、第 6実施例のマルチプロセッサ システムでは、クライアントプロセッサの手続要求プログラムが図 20の dispatch後処 理を行い、サーバプロセッサの手続呼出プログラムが図 21の手続呼出処理を行う。
[0053] 図 20の dispatch後処理は、 " dispatch"を受けた後、ステップ 181で、実行キュー 8— 0から実行可能な手続を探す。ステップ 182で、実行可能な手続が無いかを判定 する。実行可能な手続がある時には、ステップ 183で、対象サーバプロセッサが手続 を実行中であるかを判定する。実行中であれば、ステップ 181に戻り、実行中でなけ れば、ステップ 184に進み、対象サーバプロセッサにその手続の起動を指示する。そ して、ステップ 185で、対象サーバプロセッサの状態を実行中に変更してステップ 18 1に戻る。
[0054] ステップ 182で、実行可能な手続が無 、と判定された時には、ステップ 186で、す ベてのサーバプロセッサ 1— 1、 1— 2、 1—3の実行状況を調査し、ステップ 187で、 手続が完了したサーバプロセッサがあるかを判定する。無ければステップ 186に戻り 、いずれかのサーバプロセッサが手続を完了するまでステップ 186と 187を繰り返す 。手続が完了したサーバプロセッサがある時には、ステップ 188で、実行キュー 8— 0 の待ち状態を変更し、ステップ 189で、そのサーバプロセッサの状態を終了に変更し て、ステップ 190で、すべての登録された手続が完了したかを判定する。完了してい れば終了し、完了して 、なければステップステップ 181に戻る。
[0055] 図 21の手続呼出処理では、クライアントプロセッサ 1—0から手続起動要求を受ける と、サーバプロセッサの手続呼出プログラムは、ステップ 201で、要求された手続を起 動し、ステップ 202で手続を実行する。手続が完了しても完了の通知は行わず、ステ ップ 203で、クライアントプロセッサ 1 0の手続要求プログラム 6からの完了確認要求 が来るまで待ち、完了確認要求が来たら完了を通知して、次の起動要求を待つ。
[0056] なお、第 6実施例のポーリング処理の利用は、第 2及び第 3実施例にも適用可能で ある。
[0057] 図 22は、本発明の第 7実施例のマルチプロセッサシステムにおける並列処理を説 明する図である。第 7実施例のマルチプロセッサシステムは、第 4実施例のように手続 完了後に他のサーバプロセッサに対して割込みで完了を通知するのではなぐプロ セッサ同士が、共有メモリ 3内に互いに読み出し及び書き込み可能な領域を有してお り、その領域に手続の実行状態を記載した実行状態テーブル 9を設ける点が、第 4実 施例と異なる。各サーバプロセッサは、割当てられた手続が完了すると、実行状態テ 一ブル 9を更新する。各サーバプロセッサは、実行状態テーブル 9を参照することで、 どの手続が完了したかを知ることができる。
[0058] 実行状態テーブル 9事態は、クライアントプロセッサ 1—0の手続要求プログラム 6に より用意される。手続要求プログラム 6は、手続呼出プログラム 7—1、 7— 2、 7— 3で の手続の登録を行って実行キュー 8— 1、 8— 2、 8— 3を作成する時に、手続が完了 した時に更新する実行状態テーブル 9の位置を指定する。このため、手続要求プロ グラム 6は、図 16の dispatch後処理を実行する。
[0059] また、手続呼出プログラムは、図 23に示す手続呼出処理を実行する。図 23の手続 呼出処理は、図 17の処理に類似しており、図 17の処理でステップ 164を削除した処 理である。
[0060] 図 24は、本発明の第 8実施例のマルチプロセッサシステムにおける並列処理を説 明する図である。第 8実施例のマルチプロセッサシステムは、逐次実行プログラムに 依存関係も一緒に記載されており、実行リスト 5を作成すると依存関係も一緒に含ま れ、実行キュー 8 0に実行する手続を登録すると、自動的に依存関係も一緒に登 録される点が第 1実施例と異なり、他は第 1実施例と同じである。従って、依存関係を 登録するまで待つ必要はなぐ "dispatch"は不要であり、実行キュー 8 0に手続と 依存関係を登録する時に、 "dispatch"と同様の処理を行う。この処理方法は、第 2か ら第 5実施例にも適用可能である。 以上、本発明の実施例を説明した力 各種の変形例が可能であるのは 、うまでもな い。

Claims

請求の範囲
[1] クライアントプロセッサと、複数のサーバプロセッサと、前記クライアントプロセッサと 前記複数のサーバプロセッサ間のデータ通信が可能なように接続する通信経路と、 を備えるマルチプロセッサシステムにおいて、前記クライアントプロセッサ力 複数の プログラムユニットを^!に記憶した逐次実行プログラムの前記プログラムユニットを前 記サーバプロセッサに割当てることにより、実行するマルチプロセッシング方法であつ て、
前記逐次実行プログラムにおける、前記複数のプログラムユニットの実行順及び前 記複数のプログラムユニットの依存関係を登録し、
登録した前記依存関係に基づいて前記複数のプログラムユニットの実行状態を管 理し、実行可能なプログラムユニットを判定して、順次サーバプロセッサに割当てて 実行することを特徴とするマルチプロセッシング方法。
[2] 前記クライアントプロセッサは、前記サーバプロセッサに前記プログラムユニットを割 当てる処理を行う手続要求プログラムを実行し、
前記サーバプロセッサは、前記プログラムユニットを実行するために呼び出す処理 を行う手続呼出プログラムを実行する請求項 1に記載のマルチプロセッシング方法。
[3] 前記手続要求プログラムは、前記複数のプログラムユニットの実行順及び前記依存 関係を登録する実行キューを生成し、
前記手続要求プログラムは、前記実行キューに基づ 、て前記複数のプログラムュ ニットの実行状態を管理し、実行可能なプログラムユニットを判定して、順次サーバプ 口セッサを呼び出し、
前記手続呼出プログラムは、割当てられたプログラムユニットの実行完了を前記手 続要求プログラムに通知する請求項 2に記載のマルチプロセッシング方法。
[4] 前記実行キューは、各プログラムユニットの実行を割当てるサーバプロセッサに関 するサーバ割当情報を有し、
前記手続要求プログラムは、前記実行キューに従って、実行可能なプログラムュニ ットを前記サーバプロセッサに割当てる請求項 3に記載のマルチプロセッシング方法
[5] 前記実行キューは、各サーバプロセッサに対応して生成される請求項 4に記載のマ ルチプロセッシング方法。
[6] 前記手続要求プログラムは、前記複数のサーバクライアントの空き状態を管理し、 実行可能なプログラムユニットを空き状態のサーバクライアントに割当てる請求項 3に 記載のマルチプロセッシング方法。
[7] 前記手続呼出プログラムは、当該クライアントプロセッサに割当てられたプログラム ユニットの実行順及び前記依存関係情報を含む実行キューを生成し、前記実行キュ 一に基づ 、て前記プログラムユニットの実行状態を管理し、実行可能なプログラムュ ニットを判定して、順次プログラムユニットを実行する請求項 2に記載のマルチプロセ ッシング方法。
[8] 前記手続呼出プログラムは、前記プログラムユニットの実行完了を他のクライアント プロセッサに通知する請求項 7に記載のマルチプロセッシング方法。
[9] 前記手続呼出プログラムは、前記プログラムユニットの実行完了を、当該プログラム ユニットに依存関係のあるプログラムユニットを実行する他のクライアントプロセッサに 通知する請求項 7に記載のマルチプロセッシング方法。
[10] クライアントプロセッサと、複数のサーバプロセッサと、前記クライアントプロセッサと 前記複数のサーバプロセッサ間のデータ通信が可能なように接続する通信経路と、 を備え、複数の手続プログラムユニットを順に記憶した逐次実行プログラムを、前記ク ライアントプロセッサ力 前記サーバプロセッサを非同期に呼び出す呼出手続を行な つて前記プログラムユニットをサーバプロセッサに割当てることにより、実行するマル チプロセッサシステムであって、
前記逐次実行プログラムから、前記複数のプログラムユニットの実行順及び前記複 数のプログラムユニットの依存関係を登録する実行キューを備え、
前記実行キューに登録された前記依存関係に基づ 、て前記複数のプログラムュ- ットの実行状態を管理し、実行可能なプログラムユニットを判定して、順次サーバプロ セッサに割当てて実行することを特徴とするマルチプロセッサシステム。
PCT/JP2006/305867 2006-03-23 2006-03-23 マルチプロセッシング方法及びマルチプロセッサシステム WO2007108133A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2006/305867 WO2007108133A1 (ja) 2006-03-23 2006-03-23 マルチプロセッシング方法及びマルチプロセッサシステム
JP2008506135A JP5003673B2 (ja) 2006-03-23 2006-03-23 マルチプロセッシング方法及びマルチプロセッサシステム
US12/235,209 US20090019259A1 (en) 2006-03-23 2008-09-22 Multiprocessing method and multiprocessor system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2006/305867 WO2007108133A1 (ja) 2006-03-23 2006-03-23 マルチプロセッシング方法及びマルチプロセッサシステム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/235,209 Continuation US20090019259A1 (en) 2006-03-23 2008-09-22 Multiprocessing method and multiprocessor system

Publications (1)

Publication Number Publication Date
WO2007108133A1 true WO2007108133A1 (ja) 2007-09-27

Family

ID=38522173

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/305867 WO2007108133A1 (ja) 2006-03-23 2006-03-23 マルチプロセッシング方法及びマルチプロセッサシステム

Country Status (3)

Country Link
US (1) US20090019259A1 (ja)
JP (1) JP5003673B2 (ja)
WO (1) WO2007108133A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013157244A1 (ja) * 2012-04-18 2013-10-24 日本電気株式会社 タスク配置装置、タスク配置方法、および、コンピュータ・プログラム
JP2013222396A (ja) * 2012-04-18 2013-10-28 Mitsubishi Electric Corp 情報処理装置および情報処理方法およびプログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS58117054A (ja) * 1981-12-29 1983-07-12 Fujitsu Ltd 処理装置の選択方式
JP2002073576A (ja) * 2000-08-31 2002-03-12 Toshiba Corp バッチジョブ制御システム
JP2004013235A (ja) * 2002-06-03 2004-01-15 Nec Corp ジョブスケジュール変更支援装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4581736A (en) * 1983-03-01 1986-04-08 Communications Satellite Corporation Multiple downlink data aggregator and system
US5974522A (en) * 1990-01-24 1999-10-26 Cornell Research Foundation, Inc. Machine for processing interrupted out-of-order instructions
JP2945498B2 (ja) * 1991-04-12 1999-09-06 富士通株式会社 システム間通信方式
JP2001027951A (ja) * 1999-07-14 2001-01-30 Fujitsu Ltd マルチプロセッサ構成の情報処理システムにおけるファイルロード装置と記録媒体
US7072936B2 (en) * 2000-12-13 2006-07-04 Riskspan, Inc. System and method for aggregating data having data and application dependencies
US6865631B2 (en) * 2000-12-14 2005-03-08 International Business Machines Corporation Reduction of interrupts in remote procedure calls
US7246353B2 (en) * 2002-06-12 2007-07-17 Microsoft Corporation Method and system for managing the execution of threads and the processing of data
US7243352B2 (en) * 2002-11-27 2007-07-10 Sun Microsystems, Inc. Distributed process runner
US20050223101A1 (en) * 2004-03-22 2005-10-06 International Business Machines Corporation Computer-implemented method, system and program product for resolving prerequisites for native applications utilizing an open service gateway initiative ( OSGi) framework
US9038070B2 (en) * 2004-09-14 2015-05-19 Synopsys, Inc. Debug in a multicore architecture
US20060112388A1 (en) * 2004-11-22 2006-05-25 Masaaki Taniguchi Method for dynamic scheduling in a distributed environment
US20070226226A1 (en) * 2006-03-23 2007-09-27 Elta Systems Ltd. Method and system for distributing processing of computerized tasks
DE602007006467D1 (de) * 2006-03-27 2010-06-24 Coherent Logix Inc Programmierung eines multiprozessorsystems

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS58117054A (ja) * 1981-12-29 1983-07-12 Fujitsu Ltd 処理装置の選択方式
JP2002073576A (ja) * 2000-08-31 2002-03-12 Toshiba Corp バッチジョブ制御システム
JP2004013235A (ja) * 2002-06-03 2004-01-15 Nec Corp ジョブスケジュール変更支援装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013157244A1 (ja) * 2012-04-18 2013-10-24 日本電気株式会社 タスク配置装置、タスク配置方法、および、コンピュータ・プログラム
JP2013222396A (ja) * 2012-04-18 2013-10-28 Mitsubishi Electric Corp 情報処理装置および情報処理方法およびプログラム
JPWO2013157244A1 (ja) * 2012-04-18 2015-12-21 日本電気株式会社 タスク配置装置、タスク配置方法、および、コンピュータ・プログラム

Also Published As

Publication number Publication date
US20090019259A1 (en) 2009-01-15
JP5003673B2 (ja) 2012-08-15
JPWO2007108133A1 (ja) 2009-08-06

Similar Documents

Publication Publication Date Title
JP3922070B2 (ja) 分散制御方法及び装置
JP5191062B2 (ja) ストレージ制御システム、ストレージ制御システムに関する操作方法、データ・キャリア及びコンピュータ・プログラム
US20090165003A1 (en) System and method for allocating communications to processors and rescheduling processes in a multiprocessor system
JP2008084009A (ja) マルチプロセッサシステム
CN101566957A (zh) 信息处理系统及任务执行控制方法
US9201691B2 (en) Method, apparatus and system for coordinating execution of tasks in a computing system having a distributed shared memory
WO2009113381A1 (ja) マルチプロセッサシステム、マルチプロセッサシステムのｏｓ間デバイス共有方法
CN106462593B (zh) 大规模并行处理数据库的系统和方法
JP6528374B2 (ja) コンピューティングシステムにおいてジョブをスケジューリングする方法、システムおよびプログラム
JP4206653B2 (ja) タスクスケジューリングシステムおよび方法、プログラム
JP2001306341A (ja) コンピュータシステムおよびコンピュータ読み取り可能な記録媒体
EP0862113A2 (en) Autonomous agent architecture
JP5003673B2 (ja) マルチプロセッシング方法及びマルチプロセッサシステム
JP3576437B2 (ja) マルチプロセッサタスク制御方法及びタスク制御装置
JP4336763B2 (ja) ジョブ管理システム
KR100459417B1 (ko) 다중 프로세서 시스템의 작업 함수 처리 방법
JP2004054562A (ja) ネットワークファイルシステム用入出力制御方法
JP2018147126A (ja) 並列プロセス実行方法
Ramachandran et al. Distributed job allocation for large-scale manycores
JP2002259640A (ja) ワークフローシステム、スケジューリングプログラム、および同プログラムを記録した記録媒体
JP2004348233A (ja) ファイル共有システム及びサーバー並びにプログラム
JP2023091314A (ja) 半導体装置、半導体装置の制御方法及びプログラム
CN114217913A (zh) 一种异构众核架构下的任务动态分配异步管理方法
JP2504833B2 (ja) 処理実行管理方式
EP4018306A1 (en) Method and processing unit for performing tasks through master slave rotation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 06729815

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2008506135

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06729815

Country of ref document: EP

Kind code of ref document: A1