WO2012008016A1 - マルチスレッド処理装置，マルチスレッド処理システム，マルチスレッド処理プログラム，及びマルチスレッド処理方法 - Google Patents

マルチスレッド処理装置，マルチスレッド処理システム，マルチスレッド処理プログラム，及びマルチスレッド処理方法 Download PDF

Info

Publication number
WO2012008016A1
WO2012008016A1 PCT/JP2010/061825 JP2010061825W WO2012008016A1 WO 2012008016 A1 WO2012008016 A1 WO 2012008016A1 JP 2010061825 W JP2010061825 W JP 2010061825W WO 2012008016 A1 WO2012008016 A1 WO 2012008016A1
Authority
WO
WIPO (PCT)
Prior art keywords
thread
response
processing
request
program
Prior art date
Application number
PCT/JP2010/061825
Other languages
English (en)
French (fr)
Inventor
隆明 三好
Original Assignee
富士通株式会社
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 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2010/061825 priority Critical patent/WO2012008016A1/ja
Priority to EP10854700.1A priority patent/EP2595058A4/en
Priority to JP2012524359A priority patent/JP5408353B2/ja
Publication of WO2012008016A1 publication Critical patent/WO2012008016A1/ja
Priority to US13/739,654 priority patent/US20130132970A1/en

Links

Images

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/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5022—Mechanisms to release resources
    • 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]
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5011—Pool
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5018—Thread allocation

Definitions

  • This case relates to a multithread processing apparatus, a multithread processing system, a multithread processing program, and a multithread processing method that perform multithread processing.
  • a program on a server terminal performs predetermined processing in response to a request (request) such as provision of data transmitted from a program on a client terminal. Execute and return a response. Thereby, the program on the client terminal can continue the processing related to the request based on the content of the response received from the program on the server terminal.
  • a request such as provision of data transmitted from a program on a client terminal.
  • FIG. 8 is a diagram illustrating a configuration example of a system 100 that performs general client-server communication.
  • the client terminal 200 and the server terminal 300 are connected to be communicable with each other via the network 250, and the server terminal 300 returns a response to the client terminal 200 in response to a request from the client terminal 200 to the server terminal 300. .
  • the client terminal 200 can execute multi-thread processing, and includes a CPU (Central Processing Unit) 210, a storage unit 220, and a transmission / reception unit 230 that execute the processing.
  • the CPU 210 reads a program stored in the storage unit 220 and performs predetermined multithread processing.
  • the storage unit 220 has a storage area for storing various data and programs.
  • the storage unit 220 reads the program stored in the storage area or stores / expands the data or program in the storage area. Used.
  • the storage unit 220 stores a client program 400, which is a multithread program using an object, which will be described later with reference to FIG. 9, and the CPU 210 reads the client program 400 and executes multithread processing.
  • the server terminal 300 includes a CPU 310, a storage unit 320, and a transmission / reception unit 330.
  • CPU 310 reads a program stored in storage unit 320 and performs a predetermined process.
  • the storage unit 320 Similar to the storage unit 220, the storage unit 320 has a storage area for storing various data and programs.
  • the storage unit 320 stores a server program 500 described later with reference to FIG. 9, and the CPU 310 executes processing in the server terminal 300.
  • the transmission / reception units 230 and 330 exchange data bidirectionally between the client terminal 200 and the server terminal 300, respectively.
  • the transmission / reception unit 230 transmits a request from the CPU 210 to the server terminal 300, receives a response from the server terminal 300, and passes it to the CPU 210.
  • FIG. 9 is a diagram illustrating a configuration example of the client program 400 and the server program 500.
  • the client program 400 is a program that operates under the multithreaded OS, and is stored in the storage unit 220 of the client terminal 200 and executed by being read from the storage unit 220 by the CPU 210 as described above.
  • the client program 400 includes a thread pool 410, an object 430, and a reception waiting loop processing thread 440.
  • the thread pool 410 stores threads used in processing by the client program 400 and is generated by the client program 400. Further, the client program 400 generates a predetermined number (three in this case) of threads 420-1 to 420-3 in the process of generating the thread pool 410.
  • reference numerals indicating threads reference numerals 420-1 to 420-3 are used when one of a plurality of threads needs to be specified, but reference numeral 420 is used when indicating an arbitrary thread.
  • the object 430 is an object having client processing, response reception processing, and response processing.
  • the client process is a process in the client program 400 and a process for transmitting a request to the server program 500 of the server terminal 300.
  • the response reception process is a process of receiving a response from the server program 500 to the request transmitted in the client process. Further, the response process is a process executed in the client program 400 regarding the response received in the response reception process.
  • the reception waiting loop processing thread 440 is a thread that executes reception waiting loop processing by a select function.
  • the reception waiting loop processing thread 440 is also simply referred to as a thread 440.
  • the thread 440 receives data indicating the start of response transmission from the thread 540 of the server program 500.
  • the select function ends when it is determined that data indicating the start of transmission of a response from the server program 500 is received, or when a time-out occurs, that is, control returns to the thread 440.
  • an unused thread (hereinafter referred to as an empty thread) of the threads 420 in the thread pool 410 is allocated by the client program 400. Is executed. As a result, the processing of the object 430 and the reception waiting loop processing by the select function are executed in the assigned thread.
  • reception waiting loop processing thread 440 is denoted by reference numeral 440 for convenience, but the reception waiting loop processing thread is actually the thread 420-2 that is a thread in the thread pool.
  • the reception waiting loop processing thread 440 is also referred to as a thread 420-2.
  • the server program 500 is stored in the storage unit 320 of the server terminal 300 and is executed by being read from the storage unit 320 by the CPU 310.
  • the server program 500 includes a thread 540 that executes request processing.
  • the thread 540 receives a request transmitted from the client program 400, executes predetermined processing for the request, and transmits a response, which is a processing result of the request, to the client program 400.
  • the thread 540 transmits data indicating the start of transmission of the response to the reception wait loop processing thread 440 of the client program 400. Then, after transmitting the data, a response to the request is transmitted to the object 430 of the client program 400.
  • the client program 400 When the client program 400 generates an object 430 having client processing, response reception processing, and response processing, the client program 400 borrows an empty thread from the thread pool 410. Then, the client program 400 associates the object 430 with the borrowed thread (here, thread 420-1) (see A101 in FIG. 9), and causes the client 430 to execute client processing.
  • the client program 400 When the client program 400 generates an object 430 having client processing, response reception processing, and response processing, the client program 400 borrows an empty thread from the thread pool 410. Then, the client program 400 associates the object 430 with the borrowed thread (here, thread 420-1) (see A101 in FIG. 9), and causes the client 430 to execute client processing.
  • the thread 420-1 instructs the reception waiting loop processing thread 440 (thread 420-2) that performs reception waiting loop processing by the select function to start reception (see A102 in FIG. 9). Then, in the thread 440, a loop process for waiting to receive a response from the server program 500 is executed. Thereafter, an arbitrary request is transmitted to the server program 500 by the thread 420-1 that executes the client process of the object 430 (see A103 in FIG. 9).
  • the thread 540 of the server program 500 waits for an arbitrary request to be transmitted from the client program 400, and receives the transmitted request. Further, the thread 540 interprets the received request and executes an arbitrary process corresponding to the request in the thread 540 that performs the request process. Next, the server program 500 transmits data indicating the start of transmission to the client program 400 in order to transmit the result of the request processing to the client program 400 (see A104 in FIG. 9).
  • the reception waiting loop processing thread 440 receives data indicating the start of transmission and notifies the thread 420-1 associated with the object 430 to that effect (see A105 in FIG. 9). .
  • the server program 500 transmits data indicating the start of transmission to the client program 400, and then transmits the execution result of the request processing to the client program 400 as a response to the request (see A106 in FIG. 9).
  • the client program 400 receives the response in the thread 420-1 associated with the object 430, and performs processing on the response.
  • FIG. 10 is a sequence diagram for explaining processing of the client program 400 and the server program 500.
  • the thread pool 410 is generated by the client program 400 (step S101).
  • a predetermined number of threads 420 are generated in the generation process (step S102). For example, in the example shown in FIG. 9, the client program 400 generates three threads 420-1 to 420-3.
  • one empty thread is borrowed from the thread pool 410 by the client program 400 (step S103).
  • the client program 400 executes the reception waiting loop process by the select function in the borrowed thread (here, thread 420-2; reception waiting loop processing thread 440), and waits for a reception start instruction (step S104). ). Thereafter, the processing of the client program 400 ends and control returns to the user (step S105).
  • the client program 400 when an arbitrary request is requested from the client program 400 by the user, the client program 400 generates an object 430 having a client process, a response receiving process, and a response process (step S106). Further, the client program 400 borrows one empty thread 420 from the thread pool 410 (step S107). The client program 400 associates the object 430 generated in step S106 with the empty thread borrowed in step S107, and activates the associated thread (here, thread 420-1) (step 420). S108).
  • the client process is executed by the thread 420-1 associated with the object 430, and the reception start loop processing thread 440 in the reception start instruction waiting state is instructed to start reception (step S109). Then, a request for the server program 500 is transmitted by the thread 420-1 that executes the client process of the object 430 (step S110).
  • the server program 500 the request is received, and an arbitrary process for the request is executed by the thread 540 (step S111).
  • the server program 500 when the processing for the request by the thread 540 is completed, the server program 500 notifies the client program 400 of the start of response transmission (step S112).
  • the client program 400 when the client program 400 is notified of the start of transmission, the client program 400 notifies the thread 420-1 associated with the object 430, which is executing the client process, to that effect. Then, the response reception process of the object 430 is executed by the thread 420-1 (step S113). Next, the server program 500 transmits a response to the client program 400 (step S114).
  • the thread 420-1 executes an arbitrary process (response process) related to the received response. Then, the thread 420-1 notifies the client program 400 of the request result (step S115). Thereafter, the borrowed threads 420-1 and 420-2 (reception waiting loop processing thread 440) are returned to the thread pool 410 by the client program 400. In addition, the client program 400 deletes (destroys) the object 430 having the client process, the response reception process, and the response process from the resources of the client terminal 200 such as the storage unit 220 (step S116).
  • the client program 400 passes the request result to the user (step S117). If the client program 400 is terminated by the user, the thread pool 410 is discarded by the client program 400 (step S118). Here, in the discarding process, the thread pool 410 discards all the threads generated in step S102 (step S119).
  • step S120 the execution of the client program 400 ends, and the client program 400 itself is discarded (step S120).
  • the request and response processing is performed as described above.
  • the process from the start of the thread 420-1 to the destruction of the processing of the threads 420-1 and 420-2 (reception waiting loop processing thread 440) (step of FIG. 10). S108 to S116) will be described in more detail.
  • FIG. 11 illustrates the processing of the thread 420-1 that performs client processing, response reception processing, and response processing, and the thread 420-2 that performs reception waiting loop processing (reception waiting loop processing thread 440) in the client program 400. It is a flowchart. First, when the client 420 of the object 430 is executed by the thread 420-1 in step S109 in FIG. 10, the reception start loop processing thread 440 in the reception start instruction waiting state is instructed to start reception (FIG. 11). Step T101).
  • Step T102 data indicating the start of transmission of a response transmitted from the server program 500 is awaited by the select function until the specified timeout time. That is, the select function waits for data from the server program 500 which means that a response can be received.
  • the thread 420-1 When the thread 420-1 instructs the reception waiting loop processing thread 440 to start reception, the thread 420-1 transmits a request to the server program 500 (step T103). Further, the reception waiting loop processing thread 440 determines whether or not the return from the select function is due to timeout (step T104).
  • the reception waiting loop processing thread 440 calls the selection function again and waits for reception (Yes route of step T104).
  • the reception waiting loop processing thread 440 sends a response to the thread 420-1.
  • a reception notification is made (see A105 in FIG. 9).
  • non-block reception means reception of a response while first performing other processing that can be performed without waiting for reception of the response.
  • a response reception process of the object 430 is performed by the thread 420-1 that has received the response reception notification in the No route of Step T104 (Step T105). Then, the thread 420-1 executes response processing of the object 430 for the response (step T106). When the response process by the thread 420-1 is completed, the borrowed threads 420-1 and 420-2 are returned to the thread pool 410 by the client program 400. Further, the client program 400 discards the object 430 that executes the client process, the response reception process, and the response process associated with the thread 420-1 (step T107).
  • the thread 420-1 associated with the object 430 is terminated.
  • a technique is known in which a session identifier is associated with a request from a client system by a process in the server system, and the server sends a response including the session identifier to the client system (for example, a patent). Reference 1).
  • Patent Document 2 a technique is known in which a new thread is generated at the start of a session in the database server and processing execution is assigned to the session, and if the session continuation is not specified when returning to the client, the session thread is terminated (for example, Patent Document 2).
  • the number of threads 420 managed by the thread pool 410 may be limited to a few, for example, depending on the client program 400.
  • the client program 400 as described above does not use the object 430 having the client process, the response reception process, and the response process while waiting for a response to be transmitted from the server program 500 by the reception wait loop processing thread 440. For this reason, there is a problem in that the storage area storing the object 430 is in a state of being wasted.
  • the present invention is not limited to this.
  • a program running on a certain terminal sends a request to another thread of its own program or another program of its own terminal, and a response is returned from another thread or the like. It is the same.
  • the storage area that stores objects having client processing, response receiving processing, and response processing in the program that sent the request is There is a problem that it is in useless state.
  • one of the purposes of this case is to achieve effective use of a storage area for storing a process and a thread associated with the process, thereby improving the processing performance of the program.
  • the present invention is not limited to the above-described object, and other effects of the present invention can be achieved by the functions and effects derived from the respective configurations shown in the embodiments for carrying out the invention which will be described later. It can be positioned as one of
  • the multi-thread processing apparatus includes a management unit that allocates an empty thread of a plurality of threads to at least one of the plurality of processes, and the one process to which the empty thread is allocated by the management unit. And a processing unit that executes a thread assigned to the first process when a request is transmitted from the first process among the plurality of processes by the processing unit. Is released to make an empty thread, and the first process is terminated. When a response to the request is received by the processing unit, a second process that executes a process related to the response among the plurality of processes is executed. An empty thread is assigned to the process.
  • the multithread processing system of the present invention is a multithread processing system comprising the above-described multithread processing apparatus of the present invention and another device connected to the multithread processing apparatus so as to communicate with each other.
  • the processing unit transmits the request to the other device, and the other device transmits the response to the request received from the processing unit to the multithread processing device.
  • the multi-thread processing program of the present invention includes a management unit that allocates an empty thread of a plurality of threads to at least one of the plurality of processes, and the management unit to which the empty thread is allocated.
  • a multi-thread processing program that causes a computer to function as a processing unit that executes one process, and the management unit transmits a request from the first process among the plurality of processes by the processing unit.
  • the plurality of The computer is configured to allocate an empty thread to a second process that executes a process related to the response of the processes. It is intended to be.
  • the multi-thread processing method of the present case assigns an empty thread of the plurality of threads to at least one of the plurality of processes, and executes the one process to which the empty thread is assigned.
  • the thread processing method when a request is transmitted from the first process among the plurality of processes, the thread assigned to the first process is released to become an empty thread, and the first When a response to the request is received, an empty thread is assigned to a second process that executes a process related to the response among the plurality of processes.
  • FIG. 1 is a diagram illustrating a configuration example of a system for performing general client-server communication. It is a figure which shows the structural example of a client program and a server program. It is a sequence diagram for demonstrating the process of a client program and a server program. It is a flowchart for demonstrating the process in the thread
  • FIG. 1 is a diagram schematically illustrating a configuration example of a system 10 that performs client-server communication as an example of the first embodiment. .
  • the system 10 includes a client terminal 20 and a server terminal 30 in the same manner as the system 100 shown in FIG. 8 described above.
  • the client terminal 20 and the server terminal 30 are connected to each other via the network 25 so that they can communicate with each other.
  • the server terminal 30 sends a response to the client terminal 20 in response to a request from the client terminal 20 to the server terminal 30. Send back.
  • the client terminal 20 can execute a multi-thread process, and includes a CPU 21, a storage unit 22, and a transmission / reception unit 23 that execute the process.
  • the CPU 21 reads the client program 40 (see FIG. 2) stored in the storage unit 22 and performs predetermined multi-thread processing, and includes a management unit 21-1 and a processing unit 21-2.
  • the management unit 21-1 generates and manages a thread pool 41 (see FIG. 2) after the client program 40 is started, and generates and manages a specified number of threads in the generated thread pool 41. When the client program 40 is terminated, the management unit 21-1 discards all the specified number of generated threads and discards the thread pool 41.
  • the management unit 21-1 expands (generates) an arbitrary object into the storage area of the storage unit 22 and deletes (destroys) the object from the storage area. Furthermore, the management unit 21-1 assigns an empty thread among the plurality of threads in the thread pool 41 to at least one object among the plurality of objects.
  • the management unit 21-1 can have a management table in which a flag indicating whether or not a thread in the thread pool 41 is an empty thread is associated with the storage area of the storage unit 22 for each thread. By referring to the management table, an empty thread can be assigned to the object. In this case, when the management unit 21-1 assigns an object to an empty thread, the flag of the thread assigned to the object in the management table is changed to a flag indicating that it is borrowed from the flag indicating the empty thread. change.
  • the processing unit 21-2 executes predetermined processing in the client program 40.
  • the processing unit 21-2 executes processing in a thread to which processing or the like is assigned by the management unit 21-1.
  • the storage unit 22 has a storage area for storing various data and programs. When the CPU 21 executes the program, the storage unit 22 reads the program stored in the storage area, and stores and expands the data and program in the storage area. Used.
  • the storage unit 22 stores a client program 40 that is a multi-thread program using an object having a predetermined process, which will be described later with reference to FIG. 2, and the multi-thread process is executed by the CPU 21.
  • the server terminal 30 includes a CPU 31, a storage unit 32, and a transmission / reception unit 33 in the same manner as the server terminal 300 shown in FIG.
  • the CPU 31 reads a later-described server program 50 stored in the storage unit 32 and performs predetermined processing. Similar to the storage unit 22, the storage unit 32 includes a storage area for storing various data and programs. Here, the memory
  • the storage units 22 and 32 include, for example, a RAM (Random Access Memory).
  • the transmission / reception units 23 and 33 transmit and receive data bidirectionally between the client terminal 20 and the server terminal 30, respectively.
  • the transmission / reception unit 23 transmits a request from the CPU 21 to the server terminal 30, receives a response from the server terminal 30, and passes it to the CPU 21.
  • the transmission / reception unit 33 receives a request from the client terminal 20 and delivers it to the CPU 31, and transmits a response from the CPU 31 to the client terminal 20.
  • Each of the transmission / reception units 23 and 33 includes a buffer memory (not shown) that temporarily stores received or transmitted data.
  • FIG. 2 is a diagram illustrating a configuration example of the client program 40 and the server program 50.
  • the client program 40 is a program that operates under the multithreaded OS, and is stored in the storage unit 22 of the client terminal 20 and executed by being read from the storage unit 22 by the CPU 21 as described above.
  • the client program 40 includes a thread pool 41, objects 43-1 and 43-2, and a reception waiting loop processing thread 44.
  • the thread pool 41 generates and manages a plurality of threads used in processing by the client program 40, and is generated by the management unit 21-1 after the client program 40 is activated.
  • the client program 40 generates a predetermined number (three in this case) of threads 42-1 to 42-3 in the process of generating the thread pool 41.
  • the thread pool 41 is provided in the management unit 21-1.
  • the object 43-1 is an object having a process in the client program 40 and a client process for transmitting a request to the server program 50 of the server terminal 30. Therefore, the object 43-1 is an object corresponding to the client process of the object 430 shown in FIG. 9 described above.
  • the object 43-1 also has a process of adding identification information for identifying the object 43-2 that executes the response process to the request transmitted to the server program 50.
  • the object 43-1 uses the start address 45 on the storage area of the storage unit 22 of the object 43-2 that executes the response process as the identification information.
  • the object 43-2 is an object that executes response processing, which is processing executed in the client program 40, with respect to the response received in the response reception processing. Therefore, the object 43-2 is an object corresponding to the response process of the object 430 shown in FIG. 9 described above.
  • reference numerals indicating threads reference numerals 42-1 to 42-3 are used when one of a plurality of threads needs to be specified, but reference numeral 42 is used when indicating an arbitrary thread.
  • reference numerals 43-1 and 43-2 are used when one of a plurality of objects needs to be specified, but reference numeral 43 is used when an arbitrary object is indicated.
  • the reception waiting loop processing thread 44 is a thread for executing a reception waiting loop process by a select function and executing a response reception process. Therefore, the response reception process of the object 430 shown in FIG. 9 described above is executed by the reception wait loop processing thread 44.
  • the reception waiting loop processing thread 44 is also simply referred to as a thread 44.
  • the thread 44 receives data indicating the start of response transmission and also receives a response from the thread 54 of the server program 50.
  • the select function ends when it is determined that data indicating the start of transmission of a response from the server program 50 is received, or when a time-out occurs, that is, the control returns to the thread 44.
  • the thread 44 receives a response from the server program 50 to the request transmitted in the client process as a response reception process. Furthermore, in this embodiment, the thread 44 takes out the head address 45 of the object 43-2 added to the response by the server program 50, as will be described later. Then, the thread 44 borrows an empty thread from the thread pool 41, associates the thread with the start address 45 of the object 43-2 that performs the response process, and executes the thread 42-3 that performs the response process.
  • the processing by the thread 44 is executed by the client program 40 assigning an empty thread in the thread pool 41 to the reception waiting loop processing by the select function.
  • the processing by the thread 44 is executed before the request transmission processing by the thread 42-1 associated with the object 43-1 is started.
  • the thread 42-1 is assigned to the object 43-1 and the thread 42-3 is assigned to the object 43-2 by the management unit 41-1.
  • the management unit 21-1 assigns the thread 42-2 in the thread pool 41 to the reception waiting loop process and the response reception process by the select function.
  • the reception waiting loop processing thread 44 is denoted by 44 for convenience, but in actuality, the reception waiting loop processing thread is a thread 42-2 which is a thread in the thread pool.
  • the reception waiting loop processing thread 44 is also referred to as a thread 42-2.
  • the server program 50 is stored in the storage unit 32 of the server terminal 30 and is executed by being read from the storage unit 32 by the CPU 31.
  • the server program 50 includes a thread 54 that executes request processing.
  • the thread 54 receives the request transmitted from the client program 40, extracts the start address 45 of the object 43-2 added to the request, and stores it in the storage unit 32.
  • the thread 54 adds the head address 45 of the object 43-2 stored in the storage unit 32 to the response that is the processing result of the request, and transmits the response to the reception waiting loop processing thread 44.
  • the thread 54 transmits data indicating the start of response transmission to the reception waiting loop processing thread 44 of the client program 40. After the transmission of the data, the thread 54 transmits a response with the start address 45 of the object 43-2 added to the reception waiting loop processing thread 44.
  • the thread 42-1 instructs the reception waiting loop processing thread 44 (thread 42-2) that performs reception waiting loop processing by the select function to start reception (see A2 in FIG. 2). Then, in the thread 44, a loop process for waiting for reception by the select function of the response from the server program 50 is executed. Further, the thread 42-1 for executing the client process acquires the start address 45 on the storage area of the object 43-2 having the response process, and adds the acquired start address to any request data transmitted to the server program 50. An address 45 is added (see A3 in FIG. 2).
  • the thread 42-1 transmits an arbitrary request with the head address 45 added to the server program 50 (see A4 in FIG. 2).
  • the thread 54 of the server program 50 waits for an arbitrary request to be transmitted from the client program 40, receives the transmitted request, and extracts the head address 45 added to the request. Further, the thread 54 interprets the received request and executes an arbitrary process corresponding to the request in the thread 54 that performs the request process. Further, the thread 54 adds the extracted head address 45 to the response that is the result of the request processing (see A5 in FIG. 2).
  • the thread 54 transmits data indicating transmission start to the client program 40 (see A6 in FIG. 2).
  • the thread 54 transmits data indicating the start of transmission to the client program 40, and then transmits a response to which the head address 45 is added to the client program 40 (see A7 in FIG. 2).
  • the reception waiting loop processing thread 44 receives data indicating the start of transmission. Then, in the response reception process, the thread 44 receives the response with the head address 45 added, and acquires the object 43-2 from the head address 45 added to the received response (see A8 in FIG. 2). .
  • the thread 44 borrows an empty thread from the thread pool 41. Then, the thread 44 associates the acquired object 43-2 with the borrowed thread (here, the thread 42-3) (see A9 in FIG. 2).
  • the client program 40 executes response processing in the object 43-2 associated with the thread 42-3 as described above.
  • the processes in the client program 40 and the server program 50 as described above are executed as follows in the management unit 21-1 and the processing unit 21-2 in the client terminal 20 and the server terminal 30.
  • the management unit 21-1 generates a thread pool 41 and a predetermined number of threads 42 when the client program 40 is activated. Thereafter, the management unit 21-1 manages the thread 42 in the thread pool 41, and the processing unit 21-2 performs client processing (first processing), response processing (second processing), reception waiting loop processing, and When executing a response reception process or the like, the process is assigned to an empty thread.
  • the management unit 21-1 assigns a process for receiving a response to the request to the empty thread 42-2 as the reception loop processing thread 44. Further, the processing unit 21-2 starts a process of receiving a response by the reception waiting loop processing thread 44 (thread 42-2) before transmitting the request.
  • the processing unit 21-2 identifies identification information for identifying (specifying) the response process (second process) in the process of the thread 42-1, that is, the object 43- having the response process in the present embodiment. 2 is added to the top address 45 and the request is transmitted.
  • the processing unit 21-2 transmits a request from the client process (first process)
  • the management unit 21-1 releases the thread 42-1 assigned to the client process and makes it an empty thread. That is, the management unit 21-1 releases the association between the object 43-1 having the client process and the thread 42-1.
  • the management unit 21-1 ends the client process (first process). That is, the management unit 21-1 deletes the object 43-1 having the client process from the storage area of the storage unit 22.
  • the server program 50 as a request transmission destination adds the identification information added to the request to the response, and sends it back to the processing unit 21-2.
  • the management unit 21-1 relates to the response among the plurality of processes based on the identification information added to the response received by the processing unit 21-2.
  • An empty thread is assigned to the response process (second process) for executing the process. That is, the management unit 21-1 assigns the object 43-2 having response processing to the empty thread 42-3.
  • FIG. 3 is a sequence diagram for explaining processing of the client program 40 and the server program 50.
  • the thread pool 41 is generated by the client program 40 (step S1).
  • a predetermined number of threads 42 are generated in the generation process (step S2).
  • the client program 40 generates three threads 42-1 to 42-3.
  • one empty thread is borrowed from the thread pool 41 by the client program 40 (step S3).
  • the client program 40 executes a reception waiting loop process by a select function using a borrowed thread (here, thread 42-2; reception waiting loop processing thread 44), and enters a state of waiting for a reception start instruction (Ste S4). Thereafter, the processing of the client program 40 ends and control returns to the user (step S5).
  • the client program 40 when the user requests an arbitrary request to the client program 40, the client program 40 generates an object 43-1 having a client process and an object 43-2 having a response process (step S6). Also, one empty thread 42 is borrowed from the thread pool 41 by the client program 40 (step S7). Then, the client program 40 associates the object 43-1 having the client process generated in step S6 with the empty thread borrowed in step S7, and the associated thread (here, thread 42-1). Is activated (step S8).
  • a client process is executed by the thread 42-1 associated with the object 43-1, and an instruction to start reception is given to the reception waiting loop processing thread 44 in the reception start instruction waiting state (step S9).
  • a request for the server program 50 is transmitted by the thread 42-1 for executing the client process of the object 43-1 (step S10).
  • the thread 42-1 transmits the request by adding the head address 45 of the object 43-2 having response processing to the request, and when the transmission is completed, the request transmission has been transmitted to the client program. 40 is notified. When notified that the request has been transmitted, the client program 40 returns the borrowed thread 42-1 to the thread pool 41 and discards the generated object 43-1.
  • the client program 40 can use the storage area of the storage unit 22 where the object 43-1 has been developed for other processing. Further, since the thread 42-1 associated with the object 43-1 becomes an empty thread by being returned, the client program 40 can allocate the thread 42-1 to another process.
  • the request is received, and an arbitrary process for the request is executed by the thread 54 (step S11).
  • the start address 45 of the object 43-2 having the response process added to the received request is extracted by the thread 54, and temporarily stored in the storage unit 32 or the like of the server terminal 30.
  • the server program 50 when the processing for the request by the thread 54 is completed, the server program 50 notifies the client program 40 of the start of response transmission (step S12). On the other hand, when the client program 40 is notified of the start of transmission, the client program 40 notifies the thread 42-2 (reception waiting loop processing thread 44) of executing the response reception processing. In the client program 40, response reception processing is executed by the reception waiting loop processing thread 44 (step S13).
  • a response is transmitted to the client program 40 by the thread 54 of the server program 50 (step S14).
  • the thread 54 extracts the start address 45 of the object 43-2 having the response process temporarily stored in the storage unit 32 or the like, and transmits it with the response.
  • the thread 44 extracts the start address 45 of the object 43-2 having response processing from the received response, and acquires the object 43-2.
  • the thread 44 borrows an empty thread from the thread pool 41 and associates the acquired object 43-2 with the empty thread (here, the thread 42-3). Further, the thread 42-3 is activated by the thread 44. Then, an arbitrary response process is executed by the thread 42-3, and the result of the response process is notified to the client program 40 (step S15).
  • the borrowed thread 42-3 is returned to the thread pool 41 by the client program 40. Further, the client program 40 deletes (destroys) the object 43-2 having the response process from the storage area of the storage unit 22, that is, the resource of the client terminal 20 (step S16). Finally, the client program 40 passes the request result to the user (step S17).
  • the thread pool 41 is discarded by the client program 40 (step S18).
  • the thread pool 41 discards all the threads generated in step S2 (step S19). Then, the execution of the client program 40 ends, and the client program 40 itself is discarded (step S20).
  • the request and response processing is performed as described above.
  • FIG. 4 regarding the processing of the threads 42-1 to 42-3, the process from the start of the thread 42-1 to the destruction of the thread 42-3 (steps S8 to S16 in FIG. 3). ) Will be described in more detail.
  • FIG. 4 illustrates processing of the thread 42-1 for performing client processing, the thread 42-2 for performing reception waiting loop processing (the reception waiting loop processing thread 44), and the thread 42-3 for performing response processing in the client program 40. It is a flowchart for. First, when client processing of the object 43-1 is started by the thread 42-1 in step S9 of FIG. 3, the reception waiting loop processing thread 44 in the reception start instruction waiting state is instructed to start receiving ( Step T1 in FIG.
  • Step T2 data indicating the start of transmission of a response transmitted from the server program 50 is awaited by the select function until the specified timeout time ( Step T2). That is, data indicating that a response from the server program 50 can be received is awaited by the select function.
  • the thread 42-1 When the thread 42-1 is instructed to start reception to the reception wait loop processing thread 44, the thread 42-1 transmits an arbitrary request to the server program 50 (step T3). At this time, the thread 42-1 adds the head address 45 to the object 43-2 having response processing to the request and transmits it, and notifies the client program 40 that the request has been transmitted.
  • the client program 40 When the transmission of the request is notified from the thread 42-1, the client program 40 releases the association between the object 43-1 and the thread 42-1 and returns the thread 42-1 to the thread pool 41 ( Step T4). Further, the client program 40 discards the object 43-1 having the client process (step T5).
  • the thread 42-1 for executing the client process is terminated.
  • data indicating the start of transmission of a response transmitted from the server program 50 is awaited by the select function after step T1 described above.
  • the select function ends when data indicating the start of response transmission is received or when a specified timeout time elapses, and control returns to the thread 44.
  • step T6 it is determined whether or not the return from the select function is due to a timeout. If it is determined that the thread 44 has returned from the select function due to a timeout, the thread 44 calls the select function again and waits for reception (Yes route of step T6).
  • the response is received from the server program 50 by the response reception process executed by the thread 44. Response is received. At this time, the top address 45 of the object 43-2 having the response process added to the response is acquired by the thread 44 (step T7).
  • an empty thread is borrowed from the thread pool 41 by the thread 44 in which the response reception process is executed (step T8). Then, the thread 44 associates the start address 45 of the acquired object 43-2 having the response process with the empty thread (42-3 in this case), and starts the thread 42-3 for executing the response process. (Step T9).
  • response processing for the response received by the thread 44 is executed by the thread 42-3 that executes response processing (step T10).
  • the client program 40 releases the association between the object 43-2 and the thread 42-3 and returns the thread 42-3 to the thread pool 41 (step T11). Further, the client program 40 discards the object 43-2 having response processing (step T12).
  • the processing unit 21-2 performs client processing (first processing) of a plurality of processes, that is, When a request is transmitted from the object 43-1 having a client process, the management unit 21-1 releases the thread 42-1 assigned to the client process (first process) to be an empty thread. Then, the client process (first process) is ended by the management unit 21-1. That is, the management unit 21-1 deletes the object 43-1 having the client process from the storage area of the storage unit 22.
  • the management unit 21-1 assigns an empty thread to a response process that executes a process related to the response among the plurality of processes. That is, the management unit 21-1 assigns the object 43-2 having response processing to the empty thread 42-3.
  • the client process (object 43-1) that transmits a request and the response process (object 43-2) that executes a process related to a response are separated.
  • the management unit 21-1 releases the thread 42-1 to which the client process (first process) is assigned, and makes it an empty thread. That is, the management unit 21-1 can release the association between the object 43-1 having the client process and the thread 42-1, and can release the storage area of the storage unit 22 in which the object 43-1 is stored.
  • the storage area of the storage unit 22 can be used for other purposes, and the storage area can be effectively used. Also, by releasing the thread 42-1 to make it an empty thread, the thread 42-1 can be used for other processing, the thread can be used effectively, and the processing performance of the client program 40 is improved. Can be made.
  • the management unit 21-1 assigns an empty thread to the response process (second process). That is, since the management unit 21-1 assigns an empty thread 43-3 to the object 43-2 having a response process, the thread 43-3 may be set as an empty thread until the response is received after the request is transmitted. it can.
  • the processing unit 21-2 uses the identification information for identifying the response process (second process), that is, the book In the embodiment, the start address 45 of the object 43-2 having response processing is added, and the request is transmitted.
  • the management unit 21-1 causes the processing unit 21-2 to Based on the identification information added to the received response, an empty thread is assigned to the response process (second process) for executing the process related to the response. That is, the management unit 21-1 assigns the object 43-2 having response processing to the empty thread 42-3.
  • the processing unit 21-2 identifies in the client process (first process) the process for restarting the client program 40 after receiving the response from the server program 50 in response to the request to be transmitted. Add information.
  • the processing unit 21-2 sets the start address 45 of the object 43-2 having a response process as identification information for identifying the response process (second process) in response to a request to be transmitted. Append.
  • the thread 44 reliably identifies the object 43-2 having a response process based on the identification information when receiving the response, so that the response process, The restart process of the client program 40 can be executed.
  • the management unit 21-1 as an example of the present embodiment includes a thread pool 41 that generates and manages a plurality of threads 42 in advance. As described above, the management unit 21-1 generates a plurality of threads 42 in the thread pool 41 in advance, so that client processing (first processing), response processing (second processing), and reception waiting loop processing are performed. And response reception processing and the like can be assigned to an existing empty thread. As a result, the client program 40 (management unit 21-1) does not need to generate a thread each time client processing and response processing, reception waiting loop processing, response reception processing, and the like are assigned, thereby improving the processing performance of the client program 40. Can be made.
  • the client program 40 'and the server program 50' as modified examples have the same configurations as those of the client program 40 and the server program 50 as an example of the first embodiment described above unless otherwise specified. Therefore, the description is omitted.
  • a generation function 46 that generates an object 43-2 as identification information for identifying the object 43-2 instead of the start address 45 of the object 43-2.
  • the function pointer 47 is added.
  • FIG. 5 is a diagram showing a configuration example of the client program 40 ′ and the server program 50 ′.
  • the client program 40 ′ replaces the object 43-1 ′ with the object 43-1 ′ and the reception waiting loop processing thread instead of the reception waiting loop processing thread 44. 44 'is provided.
  • the client program 40 ′ is newly provided with an object generation function 46 and a function pointer 47.
  • the object 43-1 ′ generates a generation function 46 for generating the object 43-1 by the processing unit 21-2 in response to a request transmitted in the thread 42-1.
  • the function pointer 47 is added.
  • the reception waiting loop processing thread 44 ' (hereinafter also simply referred to as thread 44') generates an object 43-2 added to the response by the server program 50 'as will be described later in the response reception processing by the processing unit 21-2.
  • the function pointer 47 of the generation function 46 to be extracted is taken out.
  • the thread 44 ′ uses the processing unit 21-2 to call the generation function 46 that generates the object 43-2 having the response process by using the extracted function pointer 47 to generate the object 43-2.
  • the object 43-2 is not generated until the function pointer 47 is extracted from the response received by the thread 44 'from the server program 50' after the client program 40 'is activated.
  • the thread 42-1 is assigned to the object 43-1 ′ and the thread 42-3 is assigned to the object 43-2 by the management unit 41-1.
  • the management unit 21-1 assigns the thread 42-2 in the thread pool 41 to the reception waiting loop process and the response reception process by the select function. Therefore, for convenience, the reception waiting loop processing thread 44 'is denoted by 44', but in actuality, the reception waiting loop processing thread is a thread 42-2 which is a thread in the thread pool.
  • the reception waiting loop processing thread 44 ′ is also referred to as a thread 42-2.
  • the server program 50 ′ includes a thread 54 ′ instead of the thread 54 as compared with the server program 50 shown in FIG. 2 described above.
  • the thread 54 ′ takes out the function pointer 47 added to the request received from the client program 40 ′ and stores it in the storage unit 32.
  • the thread 54 ′ adds a function pointer 47 stored in the storage unit 32 to the response that is the processing result of the request, and transmits the response to the reception waiting loop processing thread 44 ′.
  • the thread 42-1 for executing the client process acquires the function pointer 47 of the generation function 46 of the object 43-2 having the response process, and adds the acquired function pointer to any request data transmitted to the server program 50 ′. 47 is added (see A3 ′ in FIG. 5). Thereafter, the thread 42-1 transmits an arbitrary request with the function pointer 47 added to the server program 50 ′ (see A4 ′ in FIG. 5).
  • the thread 54 'of the server program 50' waits for an arbitrary request to be transmitted from the client program 40 ', receives the transmitted request, and extracts the function pointer 47 added to the request. Further, the thread 54 ′ interprets the received request and executes an arbitrary process corresponding to the request in the thread 54 that performs the request process. Furthermore, the thread 54 adds the extracted function pointer 47 to the response that is the result of the request processing (see A5 ′ in FIG. 5).
  • the thread 54 transmits data indicating the start of transmission to the client program 40' in order to transmit a response to the client program 40 '(see A6' in FIG. 5).
  • the reception waiting loop processing thread 44 ′ receives data indicating the start of transmission. Then, in the response reception process, the thread 44 ′ reads the generation function 46 from the function pointer 47 added to the received response (see A8-1 in FIG. 5), executes the generation function 46, and executes the object 43-2. (See A8-2 in FIG. 5).
  • the thread 44 ′ borrows an empty thread from the thread pool 41.
  • the client program 40 ′ executes response processing in the object 43-2 generated as described above by the processing unit 21-2.
  • FIG. 6 is a sequence diagram for explaining the processing of the client program 40 ′ and the server program 50 ′.
  • steps S6 ′, S10 ′, S11 ′, S14 ′ and S15 ′ are executed in place of steps S6, S10, S11, S14 and S15 shown in FIG.
  • steps denoted by the same reference numerals as those already described indicate the same or substantially the same steps, and a part of the description thereof is omitted.
  • the client program 40 generates an object 43-1 having client processing (step S6 ').
  • the storage area of the storage unit 22 occupied by the object 43-2 having the response process can be used for other processes.
  • the thread 42-1 is associated with the object 43-1 and the thread 42-1 is executed to instruct the reception waiting loop processing thread 44 'in the reception start instruction waiting state to start receiving (Steps S7 to S7). S9).
  • a request for the server program 50 ′ is transmitted by the thread 42-1 that executes the client process of the object 43-1 ′ (step S10 ′).
  • the thread 42-1 transmits the request by adding the function pointer 47 of the generation function 46 that generates the object 43-2 having response processing, and when the transmission is completed,
  • the client program 40 ' is notified that the request has been transmitted.
  • the client program 40 ′ returns the borrowed thread 42-1 to the thread pool 41 and discards the generated object 43-1 ′.
  • the client program 40 can use the storage area of the storage unit 22 where the object 43-1 has been developed for other processing. Further, since the thread 42-1 associated with the object 43-1 becomes an empty thread by being returned, the client program 40 can allocate the thread 42-1 to another process.
  • the request is received, and an arbitrary process for the request is executed by the thread 54 ′ (step S11 ′).
  • the function pointer 47 added to the received request is taken out by the thread 54 ′ and temporarily held in the storage unit 32 of the server terminal 30.
  • the server program 50 notifies the client program 40 of the start of response transmission, and the client program 40' executes response reception processing by the reception waiting loop processing thread 44 '(steps S12 and S13). Next, a response is transmitted to the client program 40 'by the thread 54' of the server program 50 '(step S14').
  • the function pointer 47 of the generation function 46 that generates the object 43-2 having the response process temporarily stored in the storage unit 32 or the like is taken out by the thread 54 ′, and is sent to the response. It is added and transmitted.
  • the thread 44 ′ extracts the function pointer 47 of the generation function 46 that generates the object 43-2 having the response process from the received response.
  • the object 43-2 is generated by calling the generation function 46 by the thread 44 '.
  • an empty thread is borrowed from the thread pool 41 by the thread 44 ′, and the generated object 43-2 is associated with the empty thread (here, the thread 42-3).
  • the thread 42-3 is activated by the thread 44 '.
  • An arbitrary response process is executed by the thread 42-3, and the result of the response process is notified to the client program 40 '(step S15').
  • steps S16 to S20 the thread 42-3 is returned and the object 43-2 is deleted, and the request result is passed to the user by the client program 40 (steps S16 and S17).
  • the client program 40 is terminated by the user, the client program 40 is terminated (steps S18 to S20).
  • the request and response processing is performed as described above.
  • the process from the start of the thread 42-1 to the destruction of the thread 42-3 steps S8 ′ to S8 ′ in FIG. 6). S16) will be described in more detail.
  • FIG. 7 illustrates the processing of the thread 42-1 for performing client processing, the thread 42-2 for performing reception waiting loop processing (the reception waiting loop processing thread 44), and the thread 42-3 for performing response processing in the client program 40 ′. It is a flowchart for doing. In the procedure shown in FIG. 7, steps T3 ′ and T7-1 are executed instead of steps T3 and T7 shown in FIG. 4, and step T7-2 is newly executed. .
  • the thread 42-1 is returned to the thread pool 41, and the object 43-1 is discarded (steps T4 and T5).
  • the thread 42-1 for executing the client process is terminated.
  • the reception waiting loop processing thread 44 receives data indicating the start of response transmission from the server program 50 ′ (No route at step T 6)
  • the server program 50 is processed by the response reception processing executed by the thread 44 ′.
  • the response sent from ' is received.
  • the function pointer 47 of the generation function 46 for generating the object 43-2 having the response process added to the response is acquired by the thread 44 (step T7-1).
  • Step T7-2 the generation function 46 is called from the acquired function pointer 47 by the thread 44 ', and an object 43-2 having response processing is generated.
  • the client program 40 ′ executes the response process by associating the object 43-2 generated by the generation function 46 with the thread 42-3 by the procedure after step T8 described above.
  • client-server communication is performed according to the above-described procedure.
  • the processing unit 21-2 adds a function pointer 47 of the generation function 46 for generating the object 43-2 having the response process (second process) to the request and transmits it to the server program 50 '. Then, after receiving the response including the function pointer 47, the processing unit 21-2 calls the generation function 46 from the function pointer 47, and generates an object 43-2 having response processing.
  • the processing unit 21-2 does not generate the object 43-2 having the response process and does not use the storage area of the storage unit 22 until the response is received after the request is transmitted. Effective utilization of the area can be achieved.
  • the processing in the management unit 21-1 and the processing unit 21-2 provided by the client terminals 20, 20 ′ in the client-server communication has been described.
  • the present invention is not limited thereto. Absent.
  • the processing unit 21-2 may transmit a request to another thread or another program executed by the CPU in its own terminal. In this case, another thread or another program transmits a response to the request received from the processing unit 21-2 to the processing unit 21-2.
  • the management unit 21-1 and the processing unit 21-2 are not only used for client-server communication, but communicate with other threads or other programs executed by the CPU in its own terminal. Can also be used.
  • the CPU 21 of the client terminals 20 and 20 ′ functions as the management unit 21-1 and the processing unit 21-2 by executing the multithread program.
  • a program (multi-thread program) for realizing the functions as the management unit 21-1 and the processing unit 21-2 is, for example, a flexible disk, a CD (CD-ROM, CD-R, CD-RW, etc.). , DVD (DVD-ROM, DVD-RAM, DVD-R, DVD + R, DVD-RW, DVD + RW, HD DVD, etc.), Blu-ray disc, magnetic disc, optical disc, magneto-optical disc, etc. Provided in the form. Then, the computer reads the program from the recording medium, transfers it to the internal storage device or the external storage device, and uses it. Further, the program may be recorded in a storage device (recording medium) such as a magnetic disk, an optical disk, or a magneto-optical disk, and provided from the storage device to a computer via a communication line.
  • a storage device recording medium
  • the program stored in the internal storage device (in this embodiment, the storage unit 22 of the client terminals 20, 20 ') is stored in the microprocessor of the computer. (In this embodiment, it is executed by the CPU 21 of the client terminals 20, 20 '). At this time, the computer may read and execute the program recorded on the recording medium.
  • the computer is a concept including hardware and an operating system, and means hardware that operates under the control of the operating system. Further, when an operating system is unnecessary and hardware is operated by an application program alone, the hardware itself corresponds to a computer.
  • the hardware includes at least a microprocessor such as a CPU and means for reading a computer program recorded on a recording medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

　複数の処理のうちの少なくとも一の処理に対して複数のスレッドのうちの空スレッドを割り当てる管理部（２１－１）と、管理部（２１－１）によって空スレッドが割り当てられた一の処理を実行する処理部（２１－２）と、をそなえ、管理部（２１－１）は、処理部（２１－２）によって、複数の処理のうちの第１の処理からリクエストが送信された場合に、第１の処理に割り当てられたスレッド（４２－１）を解放して空スレッドにするとともに、第１の処理を終了させ、処理部（２１－２）によって、リクエストに対するレスポンスが受信されると、複数の処理のうちのレスポンスに関する処理を実行する第２の処理に対して空スレッドを割り当てる。

Description

マルチスレッド処理装置，マルチスレッド処理システム，マルチスレッド処理プログラム，及びマルチスレッド処理方法
　本件は、マルチスレッド処理を行なうマルチスレッド処理装置，マルチスレッド処理システム，マルチスレッド処理プログラム，及びマルチスレッド処理方法に関する。
　現在、一般的に用いられているクライアント・サーバ方式の通信では、サーバ端末上のプログラムは、クライアント端末上のプログラムから送信されるデータの提供等の要求（リクエスト）に対して、所定の処理を実行し、応答（レスポンス）を返信する。これにより、クライアント端末上のプログラムは、サーバ端末上のプログラムから受信するレスポンスの内容に基づいて、リクエストに係る処理を継続することができる。
　図８は、一般的なクライアント・サーバ間通信を行なうシステム１００の構成例を示す図である。
　クライアント端末２００及びサーバ端末３００は、ネットワーク２５０を介して相互に通信可能に接続されており、クライアント端末２００からサーバ端末３００へのリクエストに対して、サーバ端末３００がクライアント端末２００へレスポンスを返信する。
　クライアント端末２００は、マルチスレッド処理を実行することが可能であり、当該処理を実行するＣＰＵ（Central Processing Unit）２１０，記憶部２２０及び送受信部２３０をそなえる。
　ＣＰＵ２１０は、記憶部２２０に格納されたプログラムを読み出して、所定のマルチスレッド処理を行なう。
　記憶部２２０は、種々のデータやプログラムを格納する記憶領域をそなえ、ＣＰＵ２１０がプログラムを実行する際に、当該記憶領域に格納されたプログラムを読み出したり、データやプログラムを当該記憶領域に格納・展開して用いられる。
　ここで、記憶部２２０は、図９を用いて後述する、オブジェクトを用いるマルチスレッドプログラムであるクライアントプログラム４００を格納し、ＣＰＵ２１０によって、クライアントプログラム４００が読み出され、マルチスレッド処理が実行される。
　また、サーバ端末３００は、ＣＰＵ３１０，記憶部３２０及び送受信部３３０をそなえる。
　ＣＰＵ３１０は、記憶部３２０に格納されたプログラムを読み出して、所定の処理を行なう。
　記憶部３２０は、記憶部２２０と同様に、種々のデータやプログラムを格納する記憶領域をそなえる。
　ここで、記憶部３２０は、図９を用いて後述するサーバプログラム５００を格納し、ＣＰＵ３１０によって、サーバ端末３００における処理が実行される。
　送受信部２３０及び３３０は、それぞれ、クライアント端末２００及びサーバ端末３００間で双方向にデータを送受信する。
　送受信部２３０は、サーバ端末３００に対してＣＰＵ２１０からのリクエストを送信するとともに、サーバ端末３００からのレスポンスを受信してＣＰＵ２１０に受け渡す。
　また、送受信部３３０は、クライアント端末２００からのリクエストを受信してＣＰＵ３１０に受け渡すとともに、クライアント端末２００に対してＣＰＵ３１０からのレスポンスを送信する。
　図９は、クライアントプログラム４００及びサーバプログラム５００の構成例を示す図である。
　クライアントプログラム４００は、マルチスレッドＯＳ配下で動作するプログラムであり、上述のように、クライアント端末２００の記憶部２２０に格納され、ＣＰＵ２１０によって記憶部２２０から読み込まれることによって実行される。
　クライアントプログラム４００は、スレッドプール４１０，オブジェクト４３０，及び受信待ちループ処理スレッド４４０をそなえる。
　スレッドプール４１０は、クライアントプログラム４００による処理において用いられるスレッドを格納するものであり、クライアントプログラム４００によって生成される。また、クライアントプログラム４００は、スレッドプール４１０の生成過程において、所定の数（ここでは３つ）のスレッド４２０－１～４２０－３を生成する。
　以下、スレッドを示す符号としては、複数のスレッドのうちの１つを特定する必要があるときには符号４２０－１～４２０－３を用いるが、任意のスレッドを指すときには符号４２０を用いる。
　オブジェクト４３０は、クライアント処理，レスポンス受信処理及びレスポンス処理を持つオブジェクトである。
　ここで、クライアント処理は、クライアントプログラム４００における処理であるとともに、サーバ端末３００のサーバプログラム５００に対してリクエストを送信する処理である。また、レスポンス受信処理は、クライアント処理において送信したリクエストに対する、サーバプログラム５００からのレスポンスを受信する処理である。さらに、レスポンス処理は、レスポンス受信処理で受信したレスポンスに関して、クライアントプログラム４００において実行される処理である。
　受信待ちループ処理スレッド４４０は、セレクト（select）関数による受信待ちループ処理を実行するスレッドである。
　以下、受信待ちループ処理スレッド４４０を単にスレッド４４０ともいう。
　具体的には、スレッド４４０は、サーバプログラム５００のスレッド５４０から、レスポンスの送信開始を意味するデータを受信する。なお、セレクト関数は、サーバプログラム５００からレスポンスの送信開始を示すデータを受信したことを判定した場合、あるいはタイムアウトした場合に終了、すなわち、制御がスレッド４４０に復帰する。
　ここで、オブジェクト４３０が持つ処理や、セレクト関数による受信待ちループ処理は、クライアントプログラム４００によって、スレッドプール４１０内のスレッド４２０のうちの、未使用状態のスレッド（以下、空スレッドという）が割り当てられることにより実行される。これにより、オブジェクト４３０が持つ処理や、セレクト関数による受信待ちループ処理は、当該割り当てられたスレッドにおいて実行される。
　以下、オブジェクト４３０に対してスレッド４２０－１が割り当てられることとして説明する。
　また、セレクト関数による受信待ちループ処理に対してスレッド４２０－２が割り当てられることとして説明する。従って、受信待ちループ処理スレッド４４０は、便宜上、その符号を４４０としているが、実際は、受信待ちループ処理スレッドは、スレッドプール内のスレッドであるスレッド４２０－２である。以下、受信待ちループ処理スレッド４４０を、スレッド４２０－２ともいう。
　サーバプログラム５００は、上述のように、サーバ端末３００の記憶部３２０に格納され、ＣＰＵ３１０によって記憶部３２０から読み込まれることによって実行される。
　サーバプログラム５００は、リクエスト処理を実行するスレッド５４０をそなえる。
　スレッド５４０は、クライアントプログラム４００から送信されるリクエストを受信するとともに、当該リクエストに対する所定の処理を実行し、当該リクエストの処理結果であるレスポンスをクライアントプログラム４００に対して送信する。
　また、スレッド５４０は、クライアントプログラム４００へのレスポンスの送信に先立って、クライアントプログラム４００の受信待ちループ処理スレッド４４０に対してレスポンスの送信開始を意味するデータを送信する。そして、当該データの送信後、クライアントプログラム４００のオブジェクト４３０に対して、リクエストに対するレスポンスを送信する。
　次に、クライアントプログラム４００及びサーバプログラム５００の動作について説明する。
　クライアントプログラム４００は、クライアント処理，レスポンス受信処理及びレスポンス処理を持つオブジェクト４３０を生成すると、スレッドプール４１０から空スレッドを借用する。そして、クライアントプログラム４００は、オブジェクト４３０を、その借用したスレッド（ここでは、スレッド４２０－１）に関連付けて（図９中、Ａ１０１参照）、オブジェクト４３０におけるクライアント処理を実行させる。
　クライアント処理では、スレッド４２０－１は、セレクト関数による受信待ちループ処理を行なう受信待ちループ処理スレッド４４０（スレッド４２０－２）に対して、受信開始を指示する（図９中、Ａ１０２参照）。そして、スレッド４４０では、サーバプログラム５００からのレスポンスの受信待ちをするループ処理が実行される。
　その後、オブジェクト４３０が持つクライアント処理を実行するスレッド４２０－１によって、サーバプログラム５００に対して任意のリクエストが送信される（図９中、Ａ１０３参照）。
　サーバプログラム５００のスレッド５４０は、クライアントプログラム４００から任意のリクエストが送信されるのを待ち受け、送信されてきたリクエストを受信する。また、スレッド５４０は、受信したリクエストを解釈して、そのリクエストに対応する任意の処理を、リクエスト処理を行なうスレッド５４０で実行する。
　次いで、サーバプログラム５００は、リクエスト処理の結果をクライアントプログラム４００に送信するために、送信開始を意味するデータをクライアントプログラム４００に対して送信する（図９中、Ａ１０４参照）。
　クライアントプログラム４００では、受信待ちループ処理スレッド４４０において、送信開始を意味するデータを受信し、その旨をオブジェクト４３０に関連付けられているスレッド４２０－１に対して通知する（図９中、Ａ１０５参照）。
　サーバプログラム５００は、送信開始を意味するデータをクライアントプログラム４００に送信した後、リクエスト処理の実行結果を、リクエストに対するレスポンスとしてクライアントプログラム４００に送信する（図９中、Ａ１０６参照）。
　クライアントプログラム４００は、オブジェクト４３０と関連付けられているスレッド４２０－１で当該レスポンスを受信し、レスポンスに対する処理を行なう。
　次に、図１０を参照しながら、クライアントプログラム４００及びサーバプログラム５００における詳細な処理を説明する。
　図１０は、クライアントプログラム４００及びサーバプログラム５００の処理を説明するためのシーケンス図である。
　はじめに、ユーザによってクライアントプログラム４００が起動されると、クライアントプログラム４００により、スレッドプール４１０が生成される（ステップＳ１０１）。また、スレッドプール４１０においては、その生成過程において、所定の数のスレッド４２０が生成される（ステップＳ１０２）。例えば、図９に示す例においては、クライアントプログラム４００によって、スレッド４２０－１～４２０－３の３つのスレッドが生成される。
　そして、クライアントプログラム４００によって、スレッドプール４１０から空スレッドが１つ借用される（ステップＳ１０３）。また、クライアントプログラム４００により、借用されたスレッド（ここでは、スレッド４２０－２；受信待ちループ処理スレッド４４０）においてセレクト関数による受信待ちループ処理が実行され、受信開始指示待ちの状態になる（ステップＳ１０４）。その後、クライアントプログラム４００の処理が終了し、制御がユーザに戻る（ステップＳ１０５）。
　次いで、ユーザにより任意のリクエストがクライアントプログラム４００に要求されると、クライアントプログラム４００により、クライアント処理，レスポンス受信処理及びレスポンス処理を持つオブジェクト４３０が生成される（ステップＳ１０６）。
　また、クライアントプログラム４００によって、スレッドプール４１０から空スレッド４２０が１つ借用される（ステップＳ１０７）。そして、クライアントプログラム４００によって、ステップＳ１０６で生成されたオブジェクト４３０と、ステップＳ１０７で借用された空スレッドとが関連付けられ、当該関連付けられたスレッド（ここでは、スレッド４２０－１）が起動される（ステップＳ１０８）。
　続いて、オブジェクト４３０に関連付けられたスレッド４２０－１によって、クライアント処理が実行され、受信開始指示待ち状態の受信待ちループ処理スレッド４４０に対して受信開始が指示される（ステップＳ１０９）。
　そして、オブジェクト４３０が持つクライアント処理を実行するスレッド４２０－１により、サーバプログラム５００に対するリクエストが送信される（ステップＳ１１０）。
　サーバプログラム５００では、リクエストが受信され、スレッド５４０によって、そのリクエストに対する任意の処理が実行される（ステップＳ１１１）。
　サーバプログラム５００では、スレッド５４０によるリクエストに対する処理が終了すると、サーバプログラム５００によってレスポンスの送信開始がクライアントプログラム４００に対して通知される（ステップＳ１１２）。
　一方、クライアントプログラム４００では、送信開始を通知されると、その旨が、クライアント処理を実行していた、オブジェクト４３０に関連付けられたスレッド４２０－１に伝えられる。そして、当該スレッド４２０－１によって、オブジェクト４３０のレスポンス受信処理が実行される（ステップＳ１１３）。
　次いで、サーバプログラム５００によって、レスポンスがクライアントプログラム４００に対して送信される（ステップＳ１１４）。
　スレッド４２０－１がレスポンス受信処理でレスポンスを受信し終えると、当該スレッド４２０－１は、受信したレスポンスに関する任意の処理（レスポンス処理）を実行する。そして、スレッド４２０－１は、クライアントプログラム４００に対して、リクエストの結果を通知する（ステップＳ１１５）。
　その後、クライアントプログラム４００によって、借用されたスレッド４２０－１及び４２０－２（受信待ちループ処理スレッド４４０）がスレッドプール４１０に返却される。また、クライアントプログラム４００によって、クライアント処理，レスポンス受信処理及びレスポンス処理を持つオブジェクト４３０が、記憶部２２０等のクライアント端末２００のリソースから削除（破棄）される（ステップＳ１１６）。
　最後に、クライアントプログラム４００により、ユーザにリクエストの結果が渡される（ステップＳ１１７）。
　なお、ユーザによってクライアントプログラム４００が終了させられる場合、クライアントプログラム４００により、スレッドプール４１０が破棄される（ステップＳ１１８）。ここで、スレッドプール４１０は、その破棄過程において、ステップＳ１０２において生成した全てのスレッドを破棄する（ステップＳ１１９）。
　そして、クライアントプログラム４００の実行が終了し、クライアントプログラム４００自体が破棄される（ステップＳ１２０）。
　クライアント端末２００及びサーバ端末３００の間では、上述の如くリクエスト及びレスポンスの処理が行なわれる。
　次に、図１１を参照しながら、スレッド４２０－１及び４２０－２（受信待ちループ処理スレッド４４０）の処理について、スレッド４２０－１が起動されてから破棄されるまでの過程（図１０のステップＳ１０８～Ｓ１１６）をより詳細に説明する。
　図１１は、クライアントプログラム４００における、クライアント処理，レスポンス受信処理及びレスポンス処理を行なうスレッド４２０－１並びに受信待ちループ処理を行なうスレッド４２０－２（受信待ちループ処理スレッド４４０）の処理を説明するためのフローチャートである。
　はじめに、図１０のステップＳ１０９において、スレッド４２０－１により、オブジェクト４３０のクライアント処理が実行されると、受信開始指示待ち状態の受信待ちループ処理スレッド４４０に対して受信開始が指示される（図１１のステップＴ１０１）。
　次いで、スレッド４２０－１により受信開始が指示された受信待ちループ処理スレッド４４０においては、セレクト関数によって、サーバプログラム５００から送信されるレスポンスの送信開始を意味するデータが、指定タイムアウト時間まで待ち受けられる（ステップＴ１０２）。すなわち、セレクト関数によって、レスポンスの受信が可能になることを意味するサーバプログラム５００からのデータが待ち受けられる。
　そして、スレッド４２０－１では、受信待ちループ処理スレッド４４０に対して受信開始が指示されると、スレッド４２０－１によって、サーバプログラム５００に対してリクエストが送信される（ステップＴ１０３）。
　また、受信待ちループ処理スレッド４４０により、セレクト関数からの復帰が、タイムアウトによるものであるか否かが判断される（ステップＴ１０４）。
　タイムアウトによってセレクト関数から復帰したと判断された場合は、受信待ちループ処理スレッド４４０により、再度、セレクト関数が呼び出されて受信待ちになる（ステップＴ１０４のＹｅｓルート）。
　一方、ノンブロックでレスポンスが受信可能になったことによりセレクト関数から復帰したと判断された場合は（ステップＴ１０４のＮｏルート）、受信待ちループ処理スレッド４４０により、スレッド４２０－１に対してレスポンスの受信通知が行なわれる（図９中、Ａ１０５参照）。ここで、ノンブロックでの受信とは、レスポンスの受信を待たずに行なえる他の処理を先に行ないつつ、レスポンスの受信の行なうことである。
　続いて、ステップＴ１０４のＮｏルートにおいてレスポンスの受信通知を受け取ったスレッド４２０－１によって、オブジェクト４３０のレスポンス受信処理が行なわれる（ステップＴ１０５）。そして、スレッド４２０－１によって、そのレスポンスに対するオブジェクト４３０のレスポンス処理が実行される（ステップＴ１０６）。
　スレッド４２０－１によるレスポンス処理が終了すると、クライアントプログラム４００によって、借用していたスレッド４２０－１及び４２０－２がスレッドプール４１０に返却される。また、クライアントプログラム４００によって、スレッド４２０－１と関連付けられたクライアント処理，レスポンス受信処理及びレスポンス処理を実行するオブジェクト４３０が破棄される（ステップＴ１０７）。
　上述の処理により、オブジェクト４３０に関連付けられたスレッド４２０－１が終了する。
　また、従来においては、セッション識別子が、サーバ・システムにおけるプロセスによってクライアント・システムからの要求と関連付けられ、サーバは、セッション識別子を含む応答をクライアント・システムに送る技術が知られている（例えば、特許文献１）。
　さらに、データベースサーバ内でセッション開始時に新たなスレッドを生成してセッションに処理の実行を割り当てるとともに、クライアントへの返却時にセッション継続の指定がなければセッションのスレッドを終了させる技術が知られている（例えば、特許文献２）。
特表平１１－５１０６３２号公報 特開平１１－１４９４４９号公報 特開２０００－２９８１５号公報
　クライアントプログラム４００が使用する記憶部２２０の記憶領域の量を抑制するため、クライアントプログラム４００によっては、スレッドプール４１０が管理するスレッド４２０の数が、例えば２，３個に制限されることがある。
　この場合、上述のようなクライアントプログラム４００は、受信待ちループ処理スレッド４４０でサーバプログラム５００からレスポンスが送信されるのを待つ間、クライアント処理，レスポンス受信処理及びレスポンス処理を持つオブジェクト４３０は使用されない。このため、その間、オブジェクト４３０を格納している記憶領域は、無駄に使用されている状態になるという問題がある。
　また、クライアント処理，レスポンス受信処理及びレスポンス処理を持つオブジェクト４３０と関連付けされたスレッド４２０－１は、上記の間、何も処理を実行していない状態になるため、スレッドプール４１０から借用したスレッドが有効に活用されない。そのため、クライアントプログラム４００の処理性能が向上しないという問題がある。
　特許文献１～３の技術のいずれも、サーバ端末側におけるセッションやスレッドの管理に関するものであり、これらの技術によって、クライアント端末側における上述の問題を解決することは難しい。
　ここまで、図８～図１１を参照しながら、クライアント・サーバ方式の通信においてクライアント端末２００に生じる問題について説明したが、これに限られない。
　例えば、ある端末上で動作するプログラムが、自身のプログラムの他のスレッド，又は自身の端末の他のプログラム等に対してリクエストを送信するとともに、他のスレッド等からレスポンスが返信される場合においても同様である。すなわち、リクエストを送信してから、他のスレッド等からレスポンスが返信されるまでの間は、リクエストを送信したプログラムにおけるクライアント処理，レスポンス受信処理及びレスポンス処理を持つオブジェクトを格納している記憶領域は、無駄に使用されている状態になるという問題がある。
　また、リクエストを送信したプログラムにおけるクライアント処理，レスポンス受信処理及びレスポンス処理を持つオブジェクトと関連付けされたスレッドは、上記の間、何も処理を実行していない状態になるため、スレッドプールから借用したスレッドが有効に活用されない。そのため、リクエストを送信したプログラムの処理性能が向上しないという問題がある。
　上述の点に鑑み、本件の目的の１つは、処理を格納する記憶領域及び処理に関連付けられるスレッドの有効活用を図り、プログラムの処理性能の向上を実現することである。
　なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。
　本件のマルチスレッド処理装置は、複数の処理のうちの少なくとも一の処理に対して複数のスレッドのうちの空スレッドを割り当てる管理部と、該管理部によって該空スレッドが割り当てられた該一の処理を実行する処理部と、をそなえ、該管理部は、該処理部によって、該複数の処理のうちの第１の処理からリクエストが送信された場合に、該第１の処理に割り当てられたスレッドを解放して空スレッドにするとともに、該第１の処理を終了させ、該処理部によって、該リクエストに対するレスポンスが受信されると、該複数の処理のうちの該レスポンスに関する処理を実行する第２の処理に対して空スレッドを割り当てるものである。
　また、本件のマルチスレッド処理システムは、上述した本件のマルチスレッド処理装置と、該マルチスレッド処理装置と相互に通信可能に接続された他の装置と、をそなえるマルチスレッド処理システムであって、該処理部は、該他の装置に対して該リクエストを送信し、該他の装置は、該処理部から受信した該リクエストに対する該レスポンスを、該マルチスレッド処理装置に対して送信するものである。
　また、本件のマルチスレッド処理プログラムは、複数の処理のうちの少なくとも一の処理に対して複数のスレッドのうちの空スレッドを割り当てる管理部、および、該管理部によって該空スレッドが割り当てられた該一の処理を実行する処理部、として、コンピュータを機能させるマルチスレッド処理プログラムであって、該管理部は、該処理部によって、該複数の処理のうちの第１の処理からリクエストが送信された場合に、該第１の処理に割り当てられたスレッドを解放して空スレッドにするとともに、該第１の処理を終了させ、該処理部によって、該リクエストに対するレスポンスが受信されると、該複数の処理のうちの該レスポンスに関する処理を実行する第２の処理に対して空スレッドを割り当てるように、該コンピュータを機能させるものである。
　また、本件のマルチスレッド処理方法は、複数の処理のうちの少なくとも一の処理に対して複数のスレッドのうちの空スレッドを割り当てて、該空スレッドが割り当てられた該一の処理を実行するマルチスレッド処理方法であって、該複数の処理のうちの第１の処理からリクエストが送信された場合に、該第１の処理に割り当てられたスレッドを解放して空スレッドにするとともに、該第１の処理を終了させ、該リクエストに対するレスポンスが受信されると、該複数の処理のうちの該レスポンスに関する処理を実行する第２の処理に対して空スレッドを割り当てるものである。
　開示の技術によれば、処理を格納する記憶領域及び処理に関連付けられるスレッドの有効活用が図れ、プログラムの処理性能を向上させることができる。
第１実施形態の一例としてのクライアント・サーバ間通信を行なうシステムの構成例を模式的に示す図である。 第１実施形態の一例としてのクライアントプログラム及びサーバプログラムの構成例を示す図である。 クライアントプログラム及びサーバプログラムの処理を説明するためのシーケンス図である。 クライアントプログラムのスレッドにおける処理を説明するためのフローチャートである。 第１実施形態の変形例としてのクライアントプログラム及びサーバプログラムの構成例を示す図である。 クライアントプログラム及びサーバプログラムの処理の変形例を説明するためのシーケンス図である。 クライアントプログラムのスレッドにおける処理の変形例を説明するためのフローチャートである。 一般的なクライアント・サーバ間通信を行なうシステムの構成例を示す図である。 クライアントプログラム及びサーバプログラムの構成例を示す図である。 クライアントプログラム及びサーバプログラムの処理を説明するためのシーケンス図である。 クライアントプログラムのスレッドにおける処理を説明するためのフローチャートである。
　以下、図面を参照して本発明の実施の形態を説明する。
　（Ａ）第１実施形態
　（Ａ－１）第１実施形態の構成
　図１は、第１実施形態の一例としてのクライアント・サーバ間通信を行なうシステム１０の構成例を模式的に示す図である。
　図１に示すように、システム１０は、先に説明した図８に示すシステム１００と同様に、クライアント端末２０とサーバ端末３０とをそなえる。また、クライアント端末２０及びサーバ端末３０は、ネットワーク２５を介して相互に通信可能に接続されており、クライアント端末２０からサーバ端末３０へのリクエストに対して、サーバ端末３０がクライアント端末２０へレスポンスを返信する。
　クライアント端末２０は、先に説明した図８に示すクライアント端末２００と同様に、マルチスレッド処理を実行することが可能であり、当該処理を実行するＣＰＵ２１，記憶部２２及び送受信部２３をそなえる。
　ＣＰＵ２１は、記憶部２２に格納されたクライアントプログラム４０（図２参照）を読み出して、所定のマルチスレッド処理を行なうものであり、管理部２１－１と処理部２１－２とをそなえる。
　管理部２１－１は、クライアントプログラム４０の起動後に、スレッドプール４１（図２参照）を生成・管理するとともに、生成したスレッドプール４１内に指定数分のスレッドを生成・管理する。なお、管理部２１－１は、クライアントプログラム４０の終了に際して、生成した指定数分のスレッドを全て破棄するとともに、スレッドプール４１の破棄を行なう。
　また、管理部２１－１は、任意のオブジェクトの記憶部２２の記憶領域への展開（生成）及び記憶領域からのオブジェクトの削除（破棄）を行なう。
　さらに、管理部２１－１は、複数のオブジェクトのうちの少なくとも１つのオブジェクトに対して、スレッドプール４１内の複数のスレッドのうちの空スレッドを割り当てる。例えば、管理部２１－１は、記憶部２２の記憶領域等にスレッドプール４１内のスレッドが空スレッドであるか否かを示すフラグをスレッド毎に対応付けた管理テーブルをそなえることができ、この管理テーブルを参照することで、オブジェクトに対して空スレッドを割り当てることができる。この場合、管理部２１－１は、空スレッドに対してオブジェクトを割り当てた際に、管理テーブルにおいてオブジェクトに割り当てられたスレッドのフラグを、空スレッドを示すフラグから借用されていることを示すフラグに変更する。
　処理部２１－２は、クライアントプログラム４０における所定の処理を実行する。本実施形態においては、処理部２１－２は、管理部２１－１によって処理等が割り当てられたスレッドにおける処理を実行する。
　記憶部２２は、種々のデータやプログラムを格納する記憶領域をそなえ、ＣＰＵ２１がプログラムを実行する際に、当該記憶領域に格納されたプログラムを読み出したり、データやプログラムを当該記憶領域に格納・展開して用いられる。
　ここで、記憶部２２は、図２を用いて後述する、所定の処理を持つオブジェクトを用いるマルチスレッドプログラムであるクライアントプログラム４０を格納し、ＣＰＵ２１によって、マルチスレッド処理が実行される。
　また、サーバ端末３０は、先に説明した図８に示すサーバ端末３００と同様に、ＣＰＵ３１，記憶部３２及び送受信部３３をそなえる。
　ＣＰＵ３１は、記憶部３２に格納された後述するサーバプログラム５０を読み出して、所定の処理を行なう。
　記憶部３２は、記憶部２２と同様に、種々のデータやプログラムを格納する記憶領域をそなえる。
　ここで、記憶部３２は、図２を用いて後述するサーバプログラム５０を格納し、ＣＰＵ３１によって、サーバ端末３０における処理が実行される。
　なお、記憶部２２及び３２としては、例えば、ＲＡＭ（Random Access Memory）等が挙げられる。
　送受信部２３及び３３は、それぞれ、クライアント端末２０及びサーバ端末３０間で双方向にデータを送受信する。
　送受信部２３は、サーバ端末３０に対してＣＰＵ２１からのリクエストを送信するとともに、サーバ端末３０からのレスポンスを受信してＣＰＵ２１に受け渡す。
　また、送受信部３３は、クライアント端末２０からのリクエストを受信してＣＰＵ３１に受け渡すとともに、クライアント端末２０に対してＣＰＵ３１からのレスポンスを送信する。
　なお、送受信部２３及び３３は、それぞれ、受信した又は送信するデータを一時的に格納する、図示しないバッファメモリをそなえる。
　図２は、クライアントプログラム４０及びサーバプログラム５０の構成例を示す図である。
　クライアントプログラム４０は、マルチスレッドＯＳ配下で動作するプログラムであり、上述のように、クライアント端末２０の記憶部２２に格納され、ＣＰＵ２１によって記憶部２２から読み込まれることによって実行される。
　クライアントプログラム４０は、スレッドプール４１，オブジェクト４３－１，４３－２，及び受信待ちループ処理スレッド４４をそなえる。
　スレッドプール４１は、クライアントプログラム４０による処理において用いられる複数のスレッドを生成し管理するものであり、クライアントプログラム４０の起動後に管理部２１－１によって生成される。また、クライアントプログラム４０は、スレッドプール４１の生成過程において、所定の数（ここでは３つ）のスレッド４２－１～４２－３を生成する。
　なお、スレッドプール４１は、管理部２１－１にそなえられる。
　オブジェクト４３－１は、クライアントプログラム４０における処理を有するとともに、サーバ端末３０のサーバプログラム５０に対してリクエストを送信するクライアント処理を持つオブジェクトである。
　従って、オブジェクト４３－１は、先に説明した図９に示すオブジェクト４３０のクライアント処理に対応するオブジェクトである。
　また、本実施形態においては、オブジェクト４３－１は、サーバプログラム５０に送信するリクエストに対して、レスポンス処理を実行するオブジェクト４３－２を識別するための識別情報を付加する処理も有する。本実施形態においては、オブジェクト４３－１は、識別情報として、レスポンス処理を実行するオブジェクト４３－２の、記憶部２２の記憶領域上の先頭アドレス４５を用いる。
　オブジェクト４３－２は、レスポンス受信処理で受信したレスポンスに関して、クライアントプログラム４０において実行される処理であるレスポンス処理を実行するオブジェクトである。
　従って、オブジェクト４３－２は、先に説明した図９に示すオブジェクト４３０のレスポンス処理に対応するオブジェクトである。
　以下、スレッドを示す符号としては、複数のスレッドのうちの１つを特定する必要があるときには符号４２－１～４２－３を用いるが、任意のスレッドを指すときには符号４２を用いる。また、スレッドを示す符号としては、複数のオブジェクトのうちの１つを特定する必要があるときには符号４３－１，４３－２を用いるが、任意のオブジェクトを指すときには符号４３を用いる。
　受信待ちループ処理スレッド４４は、セレクト関数による受信待ちループ処理を実行するとともに、レスポンス受信処理を実行するスレッドである。
　従って、先に説明した図９に示すオブジェクト４３０のレスポンス受信処理は、受信待ちループ処理スレッド４４によって実行される。
　以下、受信待ちループ処理スレッド４４を単にスレッド４４ともいう。
　具体的には、スレッド４４は、サーバプログラム５０のスレッド５４から、レスポンスの送信開始を意味するデータを受信するとともに、レスポンスを受信する。
　なお、セレクト関数は、サーバプログラム５０からレスポンスの送信開始を示すデータを受信したことを判定した場合、あるいはタイムアウトした場合に終了、すなわち、制御がスレッド４４に復帰する。
　また、スレッド４４は、レスポンス受信処理として、クライアント処理において送信したリクエストに対する、サーバプログラム５０からのレスポンスを受信する。
　さらに、スレッド４４は、本実施形態においては、後述の如く、サーバプログラム５０によってレスポンスに付加されたオブジェクト４３－２の先頭アドレス４５を取り出す。そして、スレッド４４は、スレッドプール４１から空スレッドを借用し、そのスレッドと、取り出したレスポンス処理を行なうオブジェクト４３－２の先頭アドレス４５とを関連付け、レスポンス処理を行なうスレッド４２－３を実行する。
　また、このスレッド４４による処理は、クライアントプログラム４０により、セレクト関数による受信待ちループ処理に対して、スレッドプール４１内の空スレッドが割り当てられることによって実行される。なお、スレッド４４による処理は、オブジェクト４３－１が関連付けられたスレッド４２－１によるリクエストの送信処理が開始される前に実行される。
　以下、管理部４１－１によって、オブジェクト４３－１に対してスレッド４２－１が割り当てられ、オブジェクト４３－２に対してスレッド４２－３が割り当てられることとして説明する。また、管理部２１－１によって、セレクト関数による受信待ちループ処理及びレスポンス受信処理に対して、スレッドプール４１内のスレッド４２－２が割り当てられることとして説明する。従って、受信待ちループ処理スレッド４４は、便宜上、その符号を４４としているが、実際は、受信待ちループ処理スレッドは、スレッドプール内のスレッドであるスレッド４２－２である。以下、受信待ちループ処理スレッド４４を、スレッド４２－２ともいう。
　サーバプログラム５０は、上述のように、サーバ端末３０の記憶部３２に格納され、ＣＰＵ３１によって記憶部３２から読み込まれることによって実行される。
　サーバプログラム５０は、リクエスト処理を実行するスレッド５４をそなえる。
　スレッド５４は、クライアントプログラム４０から送信されるリクエストを受信するとともに、リクエストに付加されたオブジェクト４３－２の先頭アドレス４５を取り出し、記憶部３２に格納する。そして、スレッド５４は、リクエストの処理結果であるレスポンスに対して、記憶部３２に格納したオブジェクト４３－２の先頭アドレス４５を付加して、受信待ちループ処理スレッド４４に送信する。
　また、スレッド５４は、クライアントプログラム４０へのレスポンスの送信に先立って、クライアントプログラム４０の受信待ちループ処理スレッド４４に対してレスポンスの送信開始を意味するデータを送信する。当該データの送信後、スレッド５４は、受信待ちループ処理スレッド４４に対して、オブジェクト４３－２の先頭アドレス４５を付加したレスポンスを送信する。
　（Ａ－２）第１実施形態の動作
　次に、クライアントプログラム４０及びサーバプログラム５０の動作について説明する。
　クライアントプログラム４０は、クライアント処理を持つオブジェクト４３－１を生成すると、スレッドプール４１から空スレッドを借用する。そして、クライアントプログラム４０は、オブジェクト４３－１を、その借用したスレッド（ここでは、スレッド４２－１）に関連付けて（図２中、Ａ１参照）、オブジェクト４３－１におけるクライアント処理を実行する。
　クライアント処理では、スレッド４２－１は、セレクト関数による受信待ちループ処理を行なう受信待ちループ処理スレッド４４（スレッド４２－２）に対して、受信開始を指示する（図２中、Ａ２参照）。そして、スレッド４４では、サーバプログラム５０からのレスポンスのセレクト関数による受信待ちをするループ処理が実行される。
　また、クライアント処理を実行するスレッド４２－１は、レスポンス処理を持つオブジェクト４３－２の記憶領域上の先頭アドレス４５を取得し、サーバプログラム５０に対して送信する任意のリクエストデータに、取得した先頭アドレス４５を付加する（図２中、Ａ３参照）。
　その後、スレッド４２－１は、サーバプログラム５０に対して先頭アドレス４５を付加した任意のリクエストを送信する（図２中、Ａ４参照）。
　サーバプログラム５０のスレッド５４は、クライアントプログラム４０から任意のリクエストが送信されるのを待ち受け、送信されてきたリクエストを受信するとともに、リクエストに付加された先頭アドレス４５を取り出す。また、スレッド５４は、受信したリクエストを解釈して、そのリクエストに対応する任意の処理を、リクエスト処理を行なうスレッド５４で実行する。さらに、スレッド５４は、リクエスト処理の結果であるレスポンスに対して、取り出した先頭アドレス４５を付加する（図２中、Ａ５参照）。
　次いで、スレッド５４は、レスポンスをクライアントプログラム４０に送信するために、送信開始を意味するデータをクライアントプログラム４０に対して送信する（図２中、Ａ６参照）。
　そして、スレッド５４は、送信開始を意味するデータをクライアントプログラム４０に送信した後、先頭アドレス４５を付加したレスポンスをクライアントプログラム４０に送信する（図２中、Ａ７参照）。
　クライアントプログラム４０では、受信待ちループ処理スレッド４４が、送信開始を意味するデータを受信する。そして、スレッド４４は、レスポンス受信処理において、先頭アドレス４５が付加されたレスポンスを受信し、受信したレスポンスに付加された先頭アドレス４５から、オブジェクト４３－２を取得する（図２中、Ａ８参照）。
　また、スレッド４４は、スレッドプール４１から空スレッドを借用する。そして、スレッド４４は、取得したオブジェクト４３－２を、その借用したスレッド（ここでは、スレッド４２－３）に関連付ける（図２中、Ａ９参照）。
　以降、クライアントプログラム４０は、上述の如くスレッド４２－３に対応付けたオブジェクト４３－２におけるレスポンス処理を実行する。
　ここで、上述のようなクライアントプログラム４０及びサーバプログラム５０における処理は、クライアント端末２０及びサーバ端末３０における管理部２１－１及び処理部２１－２等において、以下のように実行される。
　管理部２１－１は、クライアントプログラム４０が起動されると、スレッドプール４１を生成するとともに、所定の数のスレッド４２を生成する。以後、管理部２１－１は、スレッドプール４１内のスレッド４２を管理し、処理部２１－２による、クライアント処理（第１の処理），レスポンス処理（第２の処理），受信待ちループ処理及びレスポンス受信処理等の実行に際して、当該処理を空スレッドに対して割り当てる。
　処理部２１－２がスレッド４２－１においてリクエストを送信する前に、管理部２１－１は、受信待ちループ処理スレッド４４として、リクエストに対するレスポンスを受信する処理を空スレッド４２－２に割り当てる。
　また、処理部２１－２は、リクエストを送信する前に、受信待ちループ処理スレッド４４（スレッド４２－２）によりレスポンスを受信する処理を開始する。
　そして、処理部２１－２は、スレッド４２－１の処理において、レスポンス処理（第２の処理）を識別（特定）するための識別情報、すなわち、本実施形態においてはレスポンス処理を持つオブジェクト４３－２の先頭アドレス４５を付加して、リクエストを送信する。
　管理部２１－１は、処理部２１－２によって、クライアント処理（第１の処理）からリクエストが送信された場合に、クライアント処理に割り当てられたスレッド４２－１を解放して空スレッドにする。すなわち、管理部２１－１は、クライアント処理を持つオブジェクト４３－１とスレッド４２－１との関連付けを解放する。そして、管理部２１－１は、クライアント処理（第１の処理）を終了させる。すなわち、管理部２１－１は、クライアント処理を持つオブジェクト４３－１を記憶部２２の記憶領域から削除する。
　一方、リクエストの送信先としてのサーバプログラム５０は、リクエストに付加された識別情報をレスポンスに付加して、処理部２１－２に対して返信する。
　管理部２１－１は、処理部２１－２によって、リクエストに対するレスポンスが受信されると、処理部２１－２が受信したレスポンスに付加された識別情報に基づいて、複数の処理のうちのレスポンスに関する処理を実行するレスポンス処理（第２の処理）に対して空スレッドを割り当てる。すなわち、管理部２１－１は、レスポンス処理を持つオブジェクト４３－２を空スレッド４２－３に割り当てる。
　次に、図３を参照しながら、クライアントプログラム４０及びサーバプログラム５０における詳細な処理を説明する。
　図３は、クライアントプログラム４０及びサーバプログラム５０の処理を説明するためのシーケンス図である。
　はじめに、ユーザによってクライアントプログラム４０が起動されると、クライアントプログラム４０により、スレッドプール４１が生成される（ステップＳ１）。また、スレッドプール４１においては、その生成過程において、所定の数のスレッド４２が生成される（ステップＳ２）。例えば、図２に示す例においては、クライアントプログラム４０によって、スレッド４２－１～４２－３の３つのスレッドが生成される。
　そして、クライアントプログラム４０によって、スレッドプール４１から空スレッドが１つ借用される（ステップＳ３）。また、クライアントプログラム４０により、借用されたスレッド（ここでは、スレッド４２－２；受信待ちループ処理スレッド４４）を用いてセレクト関数による受信待ちループ処理が実行され、受信開始指示待ちの状態になる（ステップＳ４）。その後、クライアントプログラム４０の処理が終了し、制御がユーザに戻る（ステップＳ５）。
　次いで、ユーザにより任意のリクエストがクライアントプログラム４０に要求されると、クライアントプログラム４０により、クライアント処理を持つオブジェクト４３－１及びレスポンス処理を持つオブジェクト４３－２がそれぞれ生成される（ステップＳ６）。
　また、クライアントプログラム４０によって、スレッドプール４１から空スレッド４２が１つ借用される（ステップＳ７）。そして、クライアントプログラム４０によって、ステップＳ６で生成されたクライアント処理を持つオブジェクト４３－１と、ステップＳ７で借用された空スレッドとが関連付けられ、当該関連付けられたスレッド（ここでは、スレッド４２－１）が起動される（ステップＳ８）。
　続いて、オブジェクト４３－１に関連付けられたスレッド４２－１によって、クライアント処理が実行され、受信開始指示待ち状態の受信待ちループ処理スレッド４４に対して受信開始が指示される（ステップＳ９）。
　そして、オブジェクト４３－１が持つクライアント処理を実行するスレッド４２－１により、サーバプログラム５０に対するリクエストが送信される（ステップＳ１０）。
　このとき、本実施形態においては、スレッド４２－１は、リクエストに対して、レスポンス処理を持つオブジェクト４３－２の先頭アドレス４５を付加して送信し、送信が完了すると、リクエスト送信済みをクライアントプログラム４０に通知する。リクエスト送信済みが通知されると、クライアントプログラム４０は、借用したスレッド４２－１をスレッドプール４１に返却するとともに、生成したオブジェクト４３－１を破棄する。
　これにより、クライアントプログラム４０は、オブジェクト４３－１が展開されていた記憶部２２の記憶領域を他の処理で使用できるようになる。また、オブジェクト４３－１が関連付けられていたスレッド４２－１が、返却されることにより空スレッドとなるため、クライアントプログラム４０は、スレッド４２－１を他の処理に割り当てることができるようになる。
　次いで、サーバプログラム５０では、リクエストが受信され、スレッド５４によって、そのリクエストに対する任意の処理が実行される（ステップＳ１１）。
　このとき、本実施形態においては、スレッド５４によって、受信したリクエストに付加されたレスポンス処理を持つオブジェクト４３－２の先頭アドレス４５が取り出され、サーバ端末３０の記憶部３２等に一時的に保持される。
　サーバプログラム５０では、スレッド５４によるリクエストに対する処理が終了すると、サーバプログラム５０によってレスポンスの送信開始がクライアントプログラム４０に対して通知される（ステップＳ１２）。
　一方、クライアントプログラム４０では、送信開始を通知されると、その旨が、レスポンス受信処理を実行するスレッド４２－２（受信待ちループ処理スレッド４４）に伝えられる。そして、クライアントプログラム４０では、当該受信待ちループ処理スレッド４４によって、レスポンス受信処理が実行される（ステップＳ１３）。
　次いで、サーバプログラム５０のスレッド５４によって、レスポンスがクライアントプログラム４０に対して送信される（ステップＳ１４）。
　このとき、本実施形態においては、スレッド５４によって、記憶部３２等に一時的に保持していたレスポンス処理を持つオブジェクト４３－２の先頭アドレス４５が取り出され、レスポンスに付加して送信される。スレッド４４がレスポンスを受信し終えると、本実施形態においては、スレッド４４によって、受信したレスポンスからレスポンス処理を持つオブジェクト４３－２の先頭アドレス４５が取り出され、オブジェクト４３－２が取得される。また、スレッド４４によって、スレッドプール４１から空スレッドが借用されるとともに、取得されたオブジェクト４３－２が当該空スレッド（ここでは、スレッド４２－３）に関連付けられる。さらに、スレッド４４によって、スレッド４２－３が起動される。そして、スレッド４２－３によって、任意のレスポンス処理が実行されるとともに、レスポンス処理の結果がクライアントプログラム４０に対して通知される（ステップＳ１５）。
　その後、クライアントプログラム４０によって、借用されたスレッド４２－３がスレッドプール４１に返却される。また、クライアントプログラム４０によって、レスポンス処理を持つオブジェクト４３－２が、記憶部２２の記憶領域、すなわちクライアント端末２０のリソースから削除（破棄）される（ステップＳ１６）。
　最後に、クライアントプログラム４０により、ユーザにリクエストの結果が渡される（ステップＳ１７）。
　なお、ユーザによってクライアントプログラム４０が終了させられる場合、クライアントプログラム４０により、スレッドプール４１が破棄される（ステップＳ１８）。ここで、スレッドプール４１は、その破棄過程において、ステップＳ２において生成した全てのスレッドを破棄する（ステップＳ１９）。
　そして、クライアントプログラム４０の実行が終了し、クライアントプログラム４０自体が破棄される（ステップＳ２０）。
　本実施形態におけるクライアント端末２０及びサーバ端末３０の間では、上述の如くリクエスト及びレスポンスの処理が行なわれる。
　次に、図４を参照しながら、スレッド４２－１～４２－３の処理について、スレッド４２－１が起動されてからスレッド４２－３が破棄されるまでの過程（図３のステップＳ８～Ｓ１６）をより詳細に説明する。
　図４は、クライアントプログラム４０における、クライアント処理を行なうスレッド４２－１，受信待ちループ処理を行なうスレッド４２－２（受信待ちループ処理スレッド４４）及びレスポンス処理を行なうスレッド４２－３の処理を説明するためのフローチャートである。
　はじめに、図３のステップＳ９において、スレッド４２－１により、オブジェクト４３－１のクライアント処理が開始されると、受信開始指示待ち状態の受信待ちループ処理スレッド４４に対して受信開始が指示される（図４のステップＴ１）。
　次いで、スレッド４２－１により受信開始が指示された受信待ちループ処理スレッド４４においては、セレクト関数によって、サーバプログラム５０から送信されるレスポンスの送信開始を意味するデータが、指定タイムアウト時間まで待ち受けられる（ステップＴ２）。すなわち、セレクト関数によって、サーバプログラム５０からのレスポンスの受信が可能になることを意味するデータが待ち受けられる。
　そして、スレッド４２－１では、受信待ちループ処理スレッド４４に対して受信開始が指示されると、スレッド４２－１によって、サーバプログラム５０に対して任意のリクエストが送信される（ステップＴ３）。
　このとき、スレッド４２－１により、レスポンス処理を持つオブジェクト４３－２への先頭アドレス４５がリクエストに付加されて送信されるとともに、クライアントプログラム４０に対してリクエストを送信したことが通知される。
　そして、リクエストの送信がスレッド４２－１から通知されると、クライアントプログラム４０によって、オブジェクト４３－１とスレッド４２－１との関連付けが解放され、スレッド４２－１がスレッドプール４１に返却される（ステップＴ４）。また、クライアントプログラム４０によって、クライアント処理を持つオブジェクト４３－１が破棄される（ステップＴ５）。
　これにより、クライアント処理を実行するスレッド４２－１が終了される。
　一方、受信待ちループ処理スレッド４４においては、上述したステップＴ１以降、セレクト関数によって、サーバプログラム５０から送信されるレスポンスの送信開始を意味するデータが待ち受けられている。
　ここで、セレクト関数は、上述のように、レスポンスの送信開始を意味するデータの受信又は指定タイムアウト時間の経過により終了し、制御がスレッド４４に復帰する。
　このため、スレッド４４においては、セレクト関数からの復帰が、タイムアウトによるものであるか否かが判断される（ステップＴ６）。
　スレッド４４において、タイムアウトによってセレクト関数から復帰したと判断された場合は、スレッド４４により、再度、セレクト関数が呼び出されて受信待ちになる（ステップＴ６のＹｅｓルート）。
　一方、ノンブロックでレスポンスが受信可能になったことによりセレクト関数から復帰したと判断された場合は（ステップＴ６のＮｏルート）、スレッド４４で実行されるレスポンス受信処理によって、サーバプログラム５０から送信されたレスポンスが受信される。このとき、スレッド４４によって、レスポンスに付加されたレスポンス処理を持つオブジェクト４３－２の先頭アドレス４５が取得される（ステップＴ７）。
　また、レスポンス受信処理が実行されるスレッド４４によって、スレッドプール４１から空スレッドが借用される（ステップＴ８）。そして、スレッド４４によって、取得されたレスポンス処理を持つオブジェクト４３－２の先頭アドレス４５が空スレッド（ここでは、４２－３）に関連付けられるとともに、レスポンス処理を実行するスレッド４２－３が開始される（ステップＴ９）。
　続いて、レスポンス処理を実行するスレッド４２－３によって、スレッド４４で受信したレスポンスに対するレスポンス処理が実行される（ステップＴ１０）。
　スレッド４２－３によるレスポンス処理が終了すると、クライアントプログラム４０によって、オブジェクト４３－２とスレッド４２－３との関連付けが解放され、スレッド４２－３がスレッドプール４１に返却される（ステップＴ１１）。また、クライアントプログラム４０によって、レスポンス処理を持つオブジェクト４３－２が破棄される（ステップＴ１２）。
　これにより、レスポンス処理を実行するスレッド４２－３が終了される。
　上述の手順により、クライアント・サーバ間通信が行なわれる。
　このように、本実施形態の一例としての管理部２１－１及び処理部２１－２によれば、処理部２１－２によって、複数の処理のうちのクライアント処理（第１の処理）、すなわち、クライアント処理を持つオブジェクト４３－１からリクエストが送信された場合に、管理部２１－１により、クライアント処理（第１の処理）に割り当てられたスレッド４２－１が解放されて空スレッドにされる。そして、管理部２１－１により、クライアント処理（第１の処理）が終了させられる。すなわち、管理部２１－１により、クライアント処理を持つオブジェクト４３－１が記憶部２２の記憶領域から削除される。
　また、処理部２１－２によって、リクエストに対するレスポンスが受信されると、管理部２１－１により、複数の処理のうちのレスポンスに関する処理を実行するレスポンス処理に対して空スレッドが割り当てられる。すなわち、管理部２１－１により、レスポンス処理を持つオブジェクト４３－２が空スレッド４２－３に割り当てられる。
　このように、本実施形態によれば、リクエストを送信するクライアント処理（オブジェクト４３－１）と、レスポンスに関する処理を実行するレスポンス処理（オブジェクト４３－２）とが分離される。これにより、処理部２１－２によるリクエストの送信後、管理部２１－１は、クライアント処理（第１の処理）が割り当てられたスレッド４２－１を解放して空スレッドにする。すなわち、管理部２１－１は、クライアント処理を持つオブジェクト４３－１とスレッド４２－１との関連付けを解放し、オブジェクト４３－１を格納した記憶部２２の記憶領域を解放することができる。
　従って、記憶部２２の記憶領域が他の用途に使用可能になり、記憶領域の有効活用を図ることができる。
　また、スレッド４２－１を解放して空スレッドにすることで、スレッド４２－１を他の処理に用いることが可能となり、スレッドの有効活用を図ることができ、クライアントプログラム４０の処理性能を向上させることができる。
　また、スレッド４４によるレスポンスの受信後に、管理部２１－１により、レスポンス処理（第２の処理）に対して空スレッドが割り当てられる。すなわち、管理部２１－１により、レスポンス処理を持つオブジェクト４３－２に空スレッド４３－３が割り当てられるため、リクエストの送信後レスポンスの受信までの間はスレッド４３－３を空スレッドとしておくことができる。
　従って、スレッド４４によってレスポンスが受信されるまでは、スレッド４２－３を他の処理に用いることが可能となり、スレッドの有効活用を図ることができ、クライアントプログラム４０の処理性能を向上させることができる。
　また、本実施形態の一例としての管理部２１－１及び処理部２１－２によれば、処理部２１－２により、レスポンス処理（第２の処理）を識別するための識別情報、すなわち、本実施形態においては、レスポンス処理を持つオブジェクト４３－２の先頭アドレス４５が付加されて、リクエストが送信される。そして、リクエストに付加された識別情報をリクエストの送信先としてのサーバプログラム５０により付加されたレスポンスが、処理部２１－２によって受信されると、管理部２１－１により、処理部２１－２が受信したレスポンスに付加された識別情報に基づいて、レスポンスに関する処理を実行するレスポンス処理（第２の処理）に対して空スレッドが割り当てられる。すなわち、管理部２１－１により、レスポンス処理を持つオブジェクト４３－２が空スレッド４２－３に割り当てられる。
　このように、処理部２１－２は、クライアント処理（第１の処理）において、送信するリクエストに対して、サーバプログラム５０からのレスポンスを受信後にクライアントプログラム４０が再開する処理を特定するための識別情報を付加する。本実施形態においては、処理部２１－２は、送信するリクエストに対して、レスポンス処理（第２の処理）を識別するための識別情報として、レスポンス処理を持つオブジェクト４３－２の先頭アドレス４５を付加する。これにより、クライアントプログラム４０がオブジェクト４３－１を終了させても、スレッド４４は、レスポンスの受信時に、当該識別情報に基づいてレスポンス処理を持つオブジェクト４３－２を確実に特定し、レスポンス処理、すなわち、クライアントプログラム４０の再開処理を実行することができる。
　さらに、本実施形態の一例としての管理部２１－１は、複数のスレッド４２を予め生成し管理するスレッドプール４１をそなえる。
　このように、管理部２１－１は、スレッドプール４１に予め複数のスレッド４２を生成しておくことで、クライアント処理（第１の処理）及びレスポンス処理（第２の処理）並びに受信待ちループ処理及びレスポンス受信処理等を既存の空スレッドに割り当てることができる。これにより、クライアントプログラム４０（管理部２１－１）は、クライアント処理及びレスポンス処理並びに受信待ちループ処理及びレスポンス受信処理等を割り当てる都度、スレッドを生成せずに済み、クライアントプログラム４０の処理性能を向上させることができる。
　（Ｂ）第１実施形態の変形例
　（Ｂ－１）第１実施形態の変形例の構成
　第１実施形態の一例としてのクライアントプログラム４０及びサーバプログラム５０については、上述した動作に限らず、例えば以下に図５～図７を参照しながら説明する第１実施形態の変形例のように実行してもよい。
　なお、この変形例としてのクライアントプログラム４０′及びサーバプログラム５０′においても、以下、特に説明のない限り、上述した第１実施形態の一例としてのクライアントプログラム４０及びサーバプログラム５０と同様の構成をそなえるため、その説明を省略する。
　本変形例においては、スレッド４２－１によるリクエストには、オブジェクト４３－２を識別するための識別情報として、オブジェクト４３－２の先頭アドレス４５の代わりに、オブジェクト４３－２を生成する生成関数４６の関数ポインタ４７が付加される。
　図５は、クライアントプログラム４０′及びサーバプログラム５０′の構成例を示す図である。
　クライアントプログラム４０′は、先に説明した図２に示すクライアントプログラム４０と比較して、オブジェクト４３－１の代わりにオブジェクト４３－１′を、受信待ちループ処理スレッド４４の代わりに受信待ちループ処理スレッド４４′をそなえる。
　また、クライアントプログラム４０′は、新たにオブジェクト生成関数４６及び関数ポインタ４７をそなえる。
　オブジェクト４３－１′は、図２に示すオブジェクト４３－１と比較して、処理部２１－２により、スレッド４２－１において送信されるリクエストに対して、オブジェクト４３－１を生成する生成関数４６の関数ポインタ４７を付加する点が異なる。
　受信待ちループ処理スレッド４４′（以下、単にスレッド４４′ともいう）は、処理部２１－２によるレスポンス受信処理において、後述の如く、サーバプログラム５０′によってレスポンスに付加されたオブジェクト４３－２を生成する生成関数４６の関数ポインタ４７を取り出す。そして、スレッド４４′は、処理部２１－２によって、取り出した関数ポインタ４７によってレスポンス処理を持つオブジェクト４３－２を生成する生成関数４６を呼び出して、オブジェクト４３－２を生成する。また、スレッド４４′は、管理部２１－１によって、スレッドプール４１から空スレッドを借用し、そのスレッドと、取り出したレスポンス処理を行なうオブジェクト４３－２とを関連付け、レスポンス処理を行なうスレッド４２－３を実行する。
　このように、本変形例においては、オブジェクト４３－２は、クライアントプログラム４０′が起動されてから、スレッド４４′がサーバプログラム５０′から受信したレスポンスから関数ポインタ４７を取り出すまでは生成されない。
　以下、管理部４１－１によって、オブジェクト４３－１′に対してスレッド４２－１が割り当てられ、オブジェクト４３－２に対してスレッド４２－３が割り当てられることとして説明する。また、管理部２１－１によって、セレクト関数による受信待ちループ処理及びレスポンス受信処理に対して、スレッドプール４１内のスレッド４２－２が割り当てられることとして説明する。従って、受信待ちループ処理スレッド４４′は、便宜上、その符号を４４′としているが、実際は、受信待ちループ処理スレッドは、スレッドプール内のスレッドであるスレッド４２－２である。以下、受信待ちループ処理スレッド４４′を、スレッド４２－２ともいう。
　サーバプログラム５０′は、先に説明した図２に示すサーバプログラム５０と比較して、スレッド５４の代わりにスレッド５４′をそなえる。
　スレッド５４′は、クライアントプログラム４０′から受信したリクエストに付加された関数ポインタ４７を取り出し、記憶部３２に格納する。そして、スレッド５４′は、リクエストの処理結果であるレスポンスに対して、記憶部３２に格納した関数ポインタ４７を付加して、受信待ちループ処理スレッド４４′に送信する。
　（Ｂ－２）第１実施形態の変形例の動作
　次に、クライアントプログラム４０′及びサーバプログラム５０′の動作について説明する。
　この図５に示す手順では、図２に示すＡ３～Ａ５及びＡ７に替えて、Ａ３′～Ａ５′及びＡ７′が実行されるとともに、新たにＡ８－１及びＡ８－２が実行される。また、この図５に示す手順では、図２に示すＡ８は実行されない。
　なお、図中、既述の符号と同一の符号が付された手順は、同一もしくは略同一の手順を示しているので、その説明の一部を省略する。
　以下、処理部２１－２により、スレッド４４′において、サーバプログラム５０からのレスポンスのセレクト関数による受信待ちをするループ処理が実行されている場合について説明する。
　クライアント処理を実行するスレッド４２－１は、レスポンス処理を持つオブジェクト４３－２の生成関数４６の関数ポインタ４７を取得し、サーバプログラム５０′に対して送信する任意のリクエストデータに、取得した関数ポインタ４７を付加する（図５中、Ａ３′参照）。
　その後、スレッド４２－１は、サーバプログラム５０′に対して関数ポインタ４７を付加した任意のリクエストを送信する（図５中、Ａ４′参照）。
　サーバプログラム５０′のスレッド５４′は、クライアントプログラム４０′から任意のリクエストが送信されるのを待ち受け、送信されてきたリクエストを受信するとともに、リクエストに付加された関数ポインタ４７を取り出す。また、スレッド５４′は、受信したリクエストを解釈して、そのリクエストに対応する任意の処理を、リクエスト処理を行なうスレッド５４で実行する。さらに、スレッド５４は、リクエスト処理の結果であるレスポンスに対して、取り出した関数ポインタ４７を付加する（図５中、Ａ５′参照）。
　次いで、スレッド５４′は、レスポンスをクライアントプログラム４０′に送信するために、送信開始を意味するデータをクライアントプログラム４０′に対して送信する（図５中、Ａ６′参照）。
　そして、スレッド５４′は、送信開始を意味するデータをクライアントプログラム４０′に送信した後、関数ポインタ４７を付加したレスポンスをクライアントプログラム４０′に送信する（図５中、Ａ７′参照）。
　クライアントプログラム４０′では、受信待ちループ処理スレッド４４′が、送信開始を意味するデータを受信する。そして、スレッド４４′は、レスポンス受信処理において、受信したレスポンスに付加された関数ポインタ４７から生成関数４６を読み出し（図５中、Ａ８－１参照）、生成関数４６を実行してオブジェクト４３－２を生成する（図５中、Ａ８－２参照）。
　また、スレッド４４′は、スレッドプール４１から空スレッドを借用する。そして、スレッド４４′は、生成したオブジェクト４３－２を、その借用したスレッド（ここでは、スレッド４２－３）に関連付ける（図５中、Ａ９参照）。
　以降、クライアントプログラム４０′は、処理部２１－２によって、上述の如く生成したオブジェクト４３－２におけるレスポンス処理を実行する。
　次に、図６を参照しながら、クライアントプログラム４０′及びサーバプログラム５０′における詳細な処理を説明する。
　図６は、クライアントプログラム４０′及びサーバプログラム５０′の処理を説明するためのシーケンス図である。
　この図６に示す手順では、図３に示すステップＳ６，Ｓ１０，Ｓ１１，Ｓ１４及びＳ１５に替えて、ステップＳ６′，Ｓ１０′，Ｓ１１′，Ｓ１４′及びＳ１５′が実行される。
　なお、図中、既述の符号と同一の符号が付されたステップは、同一もしくは略同一のステップを示しているので、その説明の一部を省略する。
　以下、処理部２１－２により、ユーザにより任意のリクエストがクライアントプログラム４０に要求された場合について説明する。
　クライアントプログラム４０により、クライアント処理を持つオブジェクト４３－１が生成される（ステップＳ６′）。
　このとき、本変形例では、レスポンス処理を持つオブジェクト４３－２が占有する分の記憶部２２の記憶領域を他の処理で使用することができる。
　また、オブジェクト４３－１にスレッド４２－１が関連付けられ、スレッド４２－１が実行されて、受信開始指示待ち状態の受信待ちループ処理スレッド４４′に対して受信開始が指示される（ステップＳ７～Ｓ９）。
　そして、オブジェクト４３－１′が持つクライアント処理を実行するスレッド４２－１により、サーバプログラム５０′に対するリクエストが送信される（ステップＳ１０′）。
　このとき、本変形例においては、スレッド４２－１は、リクエストに対して、レスポンス処理を持つオブジェクト４３－２を生成する生成関数４６の関数ポインタ４７を付加して送信し、送信が完了すると、リクエスト送信済みをクライアントプログラム４０′に通知する。リクエスト送信済みが通知されると、クライアントプログラム４０′は、借用したスレッド４２－１をスレッドプール４１に返却するとともに、生成したオブジェクト４３－１′を破棄する。
　これにより、クライアントプログラム４０は、オブジェクト４３－１が展開されていた記憶部２２の記憶領域を他の処理で使用できるようになる。また、オブジェクト４３－１が関連付けられていたスレッド４２－１が、返却されることにより空スレッドとなるため、クライアントプログラム４０は、スレッド４２－１を他の処理に割り当てることができるようになる。
　次いで、サーバプログラム５０′では、リクエストが受信され、スレッド５４′によって、そのリクエストに対する任意の処理が実行される（ステップＳ１１′）。
　このとき、本実施形態においては、スレッド５４′によって、受信したリクエストに付加された関数ポインタ４７が取り出され、サーバ端末３０の記憶部３２等に一時的に保持される。
　また、サーバプログラム５０′からレスポンスの送信開始がクライアントプログラム４０に対して通知され、クライアントプログラム４０′によって、受信待ちループ処理スレッド４４′によって、レスポンス受信処理が実行される（ステップＳ１２，Ｓ１３）。
　次いで、サーバプログラム５０′のスレッド５４′によって、レスポンスがクライアントプログラム４０′に対して送信される（ステップＳ１４′）。
　このとき、本変形例においては、スレッド５４′によって、記憶部３２等に一時的に保持していたレスポンス処理を持つオブジェクト４３－２を生成する生成関数４６の関数ポインタ４７が取り出され、レスポンスに付加して送信される。スレッド４４′がレスポンスを受信し終えると、本変形例においては、スレッド４４′によって、受信したレスポンスからレスポンス処理を持つオブジェクト４３－２を生成する生成関数４６の関数ポインタ４７が取り出される。そして、スレッド４４′によって、生成関数４６を呼び出すことによって、オブジェクト４３－２が生成される。また、スレッド４４′によって、スレッドプール４１から空スレッドが借用されるとともに、生成されたオブジェクト４３－２が当該空スレッド（ここでは、スレッド４２－３）に関連付けられる。さらに、スレッド４４′によって、スレッド４２－３が起動される。そして、スレッド４２－３によって、任意のレスポンス処理が実行されるとともに、レスポンス処理の結果がクライアントプログラム４０′に対して通知される（ステップＳ１５′）。
　以降、ステップＳ１６～Ｓ２０において、スレッド４２－３の返却，オブジェクト４３－２の削除がされ、クライアントプログラム４０により、ユーザにリクエストの結果が渡される（ステップＳ１６，Ｓ１７）。
　また、ユーザによってクライアントプログラム４０が終了させられる場合、クライアントプログラム４０の終了が行なわれる（ステップＳ１８～Ｓ２０）。
　本実施形態におけるクライアント端末２０及びサーバ端末３０の間では、上述の如くリクエスト及びレスポンスの処理が行なわれる。
　次に、図７を参照しながら、スレッド４２－１～４２－３の処理について、スレッド４２－１が起動されてからスレッド４２－３が破棄されるまでの過程（図６のステップＳ８′～Ｓ１６）をより詳細に説明する。
　図７は、クライアントプログラム４０′における、クライアント処理を行なうスレッド４２－１，受信待ちループ処理を行なうスレッド４２－２（受信待ちループ処理スレッド４４）及びレスポンス処理を行なうスレッド４２－３の処理を説明するためのフローチャートである。
　この図７に示す手順では、図４に示すステップＴ３及びＴ７に替えて、ステップＴ３′及びＴ７－１が実行されるとともに、新たにステップＴ７－２が実行される。。
　なお、図中、既述の符号と同一の符号が付されたステップは、同一もしくは略同一のステップを示しているので、その説明の一部を省略する。
　以下、スレッド４２－１により受信開始が指示された受信待ちループ処理スレッド４４において、レスポンスの送信開始を意味するデータが待ち受けられている場合について説明する。
　スレッド４２－１では、受信待ちループ処理スレッド４４′に対して受信開始が指示されると、スレッド４２－１によって、サーバプログラム５０′に対して任意のリクエストが送信される（ステップＴ３′）。
　このとき、スレッド４２－１により、レスポンス処理を持つオブジェクト４３－２を生成する生成関数４６の関数ポインタ４７がリクエストに付加されて送信されるとともに、クライアントプログラム４０′に対してリクエストを送信したことが通知される。
　そして、スレッド４２－１がスレッドプール４１に返却されるとともに、オブジェクト４３－１が破棄される（ステップＴ４，Ｔ５）。
　これにより、クライアント処理を実行するスレッド４２－１が終了される。
　一方、受信待ちループ処理スレッド４４において、サーバプログラム５０′からレスポンス送信開始を意味するデータを受信した場合は（ステップＴ６のＮｏルート）、スレッド４４′で実行されるレスポンス受信処理によって、サーバプログラム５０′から送信されたレスポンスが受信される。このとき、スレッド４４によって、レスポンスに付加されたレスポンス処理を持つオブジェクト４３－２を生成する生成関数４６の関数ポインタ４７が取得される（ステップＴ７－１）。
　そして、スレッド４４′によって、取得した関数ポインタ４７から生成関数４６が呼び出され、レスポンス処理を持つオブジェクト４３－２が生成される。（ステップＴ７－２）。
　以下、クライアントプログラム４０′は、上述したステップＴ８以降の手順により、生成関数４６により生成したオブジェクト４３－２をスレッド４２－３に関連付けて、レスポンス処理を実行する。
　本変形例においては、上述の手順により、クライアント・サーバ間通信が行なわれる。
　このように、本実施形態の一例としての管理部２１－１及び処理部２１－２によれば、上述した第１実施形態と同様の効果が得られる。
　また、処理部２１－２によって、レスポンス処理（第２の処理）を持つオブジェクト４３－２を生成する生成関数４６の関数ポインタ４７が、リクエストに付加されてサーバプログラム５０′に送信される。そして、関数ポインタ４７を含むレスポンスを受信後に、処理部２１－２によって、関数ポインタ４７から生成関数４６が呼び出され、レスポンス処理を持つオブジェクト４３－２が生成される。
　これにより、処理部２１－２において、リクエストを送信してからレスポンスを受信するまでの間は、レスポンス処理を持つオブジェクト４３－２を生成せず、記憶部２２の記憶領域が使用されないため、記憶領域の有効活用を図ることができる。
　（Ｃ）その他
　以上、本発明の好ましい実施形態について詳述したが、本発明は、かかる特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。
　例えば、図１～図７を参照しながら、クライアント・サーバ方式の通信において、クライアント端末２０，２０′がそなえる管理部２１－１及び処理部２１－２における処理について説明したが、これに限られない。
　例えば、処理部２１－２は、自身の端末内のＣＰＵが実行する他のスレッド又は他のプログラムに対してリクエストを送信してもよい。この場合、他のスレッド又は他のプログラムは、処理部２１－２から受信したリクエストに対するレスポンスを、処理部２１－２に対して送信する。
　このように、管理部２１－１及び処理部２１－２は、クライアント・サーバ方式の通信にのみ用いられるものではなく、自身の端末内のＣＰＵが実行する他のスレッド又は他のプログラムとの通信においても用いることができる。
　そして、クライアント端末２０，２０′のＣＰＵ２１が、マルチスレッドプログラムを実行することにより、これらの管理部２１－１及び処理部２１－２として機能するようになっている。
　なお、これらの管理部２１－１及び処理部２１－２としての機能を実現するためのプログラム（マルチスレッドプログラム）は、例えばフレキシブルディスク，ＣＤ（ＣＤ－ＲＯＭ，ＣＤ－Ｒ，ＣＤ－ＲＷ等），ＤＶＤ（ＤＶＤ－ＲＯＭ，ＤＶＤ－ＲＡＭ，ＤＶＤ－Ｒ，ＤＶＤ＋Ｒ，ＤＶＤ－ＲＷ，ＤＶＤ＋ＲＷ，ＨＤ　ＤＶＤ等），ブルーレイディスク，磁気ディスク，光ディスク，光磁気ディスク等の、コンピュータ読取可能な記録媒体に記録された形態で提供される。そして、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。また、そのプログラムを、例えば磁気ディスク，光ディスク，光磁気ディスク等の記憶装置（記録媒体）に記録しておき、その記憶装置から通信回線を介してコンピュータに提供するようにしても良い。
　管理部２１－１及び処理部２１－２としての機能を実現する際には、内部記憶装置（本実施形態ではクライアント端末２０，２０′の記憶部２２）に格納されたプログラムがコンピュータのマイクロプロセッサ（本実施形態ではクライアント端末２０，２０′のＣＰＵ２１）によって実行される。このとき、記録媒体に記録されたプログラムをコンピュータが読み取って実行するようにしても良い。
　なお、本実施形態において、コンピュータとは、ハードウェアとオペレーティングシステムとを含む概念であり、オペレーティングシステムの制御の下で動作するハードウェアを意味している。また、オペレーティングシステムが不要でアプリケーションプログラム単独でハードウェアを動作させるような場合には、そのハードウェア自体がコンピュータに相当する。ハードウェアは、少なくとも、ＣＰＵ等のマイクロプロセッサと、記録媒体に記録されたコンピュータプログラムを読み取るための手段とをそなえており、本実施形態においては、クライアント端末２０，２０′がコンピュータとしての機能を有しているのである。
　１０，１００　クライアント・サーバ間通信システム
　２０，２００　　クライアント端末
　２１，２１０，３１，３１０　　ＣＰＵ
　２１－１，３１－１　　管理部
　２１－２，３１－２　　処理部
　２２，２２０，３２，３２０　　記憶部
　２３，２３０，３３，３３０　　送受信部
　２５，２５０　　ネットワーク
　３０，３００　　サーバ端末
　４０，４００　　クライアントプログラム
　４１，４１０　　スレッドプール
　４２－１～４２－３，４２０－１～４２０－３　　スレッド
　４３－１，４３－２，４３０　　オブジェクト
　４４，４４０　　受信待ちループ処理スレッド
　４５　　先頭アドレス
　４６　　オブジェクト生成関数
　４７　　関数ポインタ
　５０，５００　　サーバプログラム
　５４，５４０　　サーバプログラム側スレッド

Claims (15)

  1. 　複数の処理のうちの少なくとも一の処理に対して複数のスレッドのうちの空スレッドを割り当てる管理部と、該管理部によって該空スレッドが割り当てられた該一の処理を実行する処理部と、をそなえ、
    　該管理部は、
    　該処理部によって、該複数の処理のうちの第１の処理からリクエストが送信された場合に、該第１の処理に割り当てられたスレッドを解放して空スレッドにするとともに、該第１の処理を終了させ、
    　該処理部によって、該リクエストに対するレスポンスが受信されると、該複数の処理のうちの該レスポンスに関する処理を実行する第２の処理に対して空スレッドを割り当てることを特徴とする、マルチスレッド処理装置。
  2. 　該処理部は、該第２の処理を識別するための識別情報を付加して、該リクエストを送信し、
    　該管理部は、該リクエストに付加された該識別情報を該リクエストの送信先により付加された該レスポンスが、該処理部によって受信されると、該処理部が受信した該レスポンスに付加された該識別情報に基づいて、該第２の処理に対して空スレッドを割り当てることを特徴とする、請求項１記載のマルチスレッド処理装置。
  3. 　該識別情報は、該第２の処理を持つオブジェクトの先頭アドレスであることを特徴とする、請求項２記載のマルチスレッド処理装置。
  4. 　該識別情報は、該第２の処理を持つオブジェクトを生成する関数の関数ポインタであることを特徴とする、請求項２記載のマルチスレッド処理装置。
  5. 　該管理部は、該複数のスレッドを予め生成し管理するスレッドプールをそなえることを特徴とする、請求項１～４のいずれか１項記載のマルチスレッド処理装置。
  6. 　該処理部が、該リクエストを送信する前に、
    　該管理部は、受信待ちスレッドとして、該リクエストに対する該レスポンスを受信する処理を該空スレッドに割り当てるとともに、
    　該処理部は、該受信待ちスレッドにより該レスポンスを受信する処理を開始することを特徴とする、請求項１～５のいずれか１項記載のマルチスレッド処理装置。
  7. 　該処理部及び該管理部は、ＣＰＵにそなえられ、
    　該処理部は、該ＣＰＵが実行する他のスレッド又は他のプログラムに対して該リクエストを送信し、
    　該他のスレッド又は他のプログラムは、該処理部から受信した該リクエストに対する該レスポンスを、該処理部に対して送信することを特徴とする、請求項１～６のいずれか１項記載のマルチスレッド処理装置。
  8. 　請求項１～６のいずれか１項記載のマルチスレッド処理装置と、該マルチスレッド処理装置と相互に通信可能に接続された他の装置と、をそなえるマルチスレッド処理システムであって、
    　該処理部は、該他の装置に対して該リクエストを送信し、
    　該他の装置は、該処理部から受信した該リクエストに対する該レスポンスを、該マルチスレッド処理装置に対して送信することを特徴とする、マルチスレッド処理システム。
  9. 　複数の処理のうちの少なくとも一の処理に対して複数のスレッドのうちの空スレッドを割り当てる管理部、および、該管理部によって該空スレッドが割り当てられた該一の処理を実行する処理部、として、コンピュータを機能させるマルチスレッド処理プログラムであって、
    　該管理部は、
    　該処理部によって、該複数の処理のうちの第１の処理からリクエストが送信された場合に、該第１の処理に割り当てられたスレッドを解放して空スレッドにするとともに、該第１の処理を終了させ、
    　該処理部によって、該リクエストに対するレスポンスが受信されると、該複数の処理のうちの該レスポンスに関する処理を実行する第２の処理に対して空スレッドを割り当てるように、
    該コンピュータを機能させることを特徴とする、マルチスレッド処理プログラム。
  10. 　該処理部は、該第２の処理を識別するための識別情報を付加して、該リクエストを送信し、
    　該管理部は、該リクエストに付加された該識別情報を該リクエストの送信先により付加された該レスポンスが、該処理部によって受信されると、該処理部が受信した該レスポンスに付加された該識別情報に基づいて、該第２の処理に対して空スレッドを割り当てるように、
    該コンピュータを機能させることを特徴とする、請求項９記載のマルチスレッド処理プログラム。
  11. 　該識別情報は、該第２の処理を持つオブジェクトの先頭アドレスであることを特徴とする、請求項１０記載のマルチスレッド処理プログラム。
  12. 　該識別情報は、該第２の処理を持つオブジェクトを生成する関数の関数ポインタであることを特徴とする、請求項１０記載のマルチスレッド処理プログラム。
  13. 　該管理部は、該複数のスレッドを予め生成し管理するスレッドプールをそなえることを特徴とする、請求項９～１２のいずれか１項記載のマルチスレッド処理プログラム。
  14. 　該処理部が、該リクエストを送信する前に、
    　該管理部は、受信待ちスレッドとして、該リクエストに対する該レスポンスを受信する処理を該空スレッドに割り当てるとともに、
    　該処理部は、該受信待ちスレッドにより該レスポンスを受信する処理を開始するように、
    該コンピュータを機能させることを特徴とする、請求項９～１３のいずれか１項記載のマルチスレッド処理プログラム。
  15. 　複数の処理のうちの少なくとも一の処理に対して複数のスレッドのうちの空スレッドを割り当てて、該空スレッドが割り当てられた該一の処理を実行するマルチスレッド処理方法であって、
    　該複数の処理のうちの第１の処理からリクエストが送信された場合に、該第１の処理に割り当てられたスレッドを解放して空スレッドにするとともに、該第１の処理を終了させ、
    　該リクエストに対するレスポンスが受信されると、該複数の処理のうちの該レスポンスに関する処理を実行する第２の処理に対して空スレッドを割り当てることを特徴とする、マルチスレッド処理方法。
PCT/JP2010/061825 2010-07-13 2010-07-13 マルチスレッド処理装置，マルチスレッド処理システム，マルチスレッド処理プログラム，及びマルチスレッド処理方法 WO2012008016A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/JP2010/061825 WO2012008016A1 (ja) 2010-07-13 2010-07-13 マルチスレッド処理装置，マルチスレッド処理システム，マルチスレッド処理プログラム，及びマルチスレッド処理方法
EP10854700.1A EP2595058A4 (en) 2010-07-13 2010-07-13 DEVICE, SYSTEM, PROGRAM, AND METHOD FOR PROCESSING MULTIPLE PATHS
JP2012524359A JP5408353B2 (ja) 2010-07-13 2010-07-13 マルチスレッド処理装置，マルチスレッド処理システム，マルチスレッド処理プログラム，及びマルチスレッド処理方法
US13/739,654 US20130132970A1 (en) 2010-07-13 2013-01-11 Multithread processing device, multithread processing system, and computer-readable recording medium having stored therein multithread processing program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/061825 WO2012008016A1 (ja) 2010-07-13 2010-07-13 マルチスレッド処理装置，マルチスレッド処理システム，マルチスレッド処理プログラム，及びマルチスレッド処理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/739,654 Continuation US20130132970A1 (en) 2010-07-13 2013-01-11 Multithread processing device, multithread processing system, and computer-readable recording medium having stored therein multithread processing program

Publications (1)

Publication Number Publication Date
WO2012008016A1 true WO2012008016A1 (ja) 2012-01-19

Family

ID=45469041

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/061825 WO2012008016A1 (ja) 2010-07-13 2010-07-13 マルチスレッド処理装置，マルチスレッド処理システム，マルチスレッド処理プログラム，及びマルチスレッド処理方法

Country Status (4)

Country Link
US (1) US20130132970A1 (ja)
EP (1) EP2595058A4 (ja)
JP (1) JP5408353B2 (ja)
WO (1) WO2012008016A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014052680A (ja) * 2012-09-05 2014-03-20 Fujitsu Ltd プロセス数制御プログラム、プロセス数制御方法、および情報処理装置
WO2017024965A1 (zh) * 2015-08-11 2017-02-16 阿里巴巴集团控股有限公司 一种数据流量限制的方法及系统

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9378045B2 (en) 2013-02-28 2016-06-28 Oracle International Corporation System and method for supporting cooperative concurrency in a middleware machine environment
US9110715B2 (en) 2013-02-28 2015-08-18 Oracle International Corporation System and method for using a sequencer in a concurrent priority queue
US10095562B2 (en) * 2013-02-28 2018-10-09 Oracle International Corporation System and method for transforming a queue from non-blocking to blocking
US8689237B2 (en) 2011-09-22 2014-04-01 Oracle International Corporation Multi-lane concurrent bag for facilitating inter-thread communication
CN109669780B (zh) * 2018-12-25 2020-02-14 上海极链网络科技有限公司 一种视频解析方法及系统
CN110008012A (zh) * 2019-03-12 2019-07-12 平安普惠企业管理有限公司 一种信号量许可的调整方法及装置
CN110134578B (zh) * 2019-05-23 2023-04-28 浙江齐治科技股份有限公司 一种数据处理方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09282189A (ja) * 1996-04-09 1997-10-31 Hitachi Ltd サーバプログラム
JP2002505471A (ja) * 1998-02-26 2002-02-19 サンマイクロシステムズ インコーポレーテッド 遠隔処理の中断および継続の方法と装置
JP2006185229A (ja) * 2004-12-28 2006-07-13 Hitachi Ltd オンライン同期処理方法及び装置

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2313524A (en) * 1996-05-24 1997-11-26 Ibm Providing communications links in a computer network
JPH11149449A (ja) * 1997-11-18 1999-06-02 Nec Corp データベースセッション管理方法及びその装置と処理を記録した記録媒体
US7380039B2 (en) * 2003-12-30 2008-05-27 3Tera, Inc. Apparatus, method and system for aggregrating computing resources
US8429655B2 (en) * 2005-04-29 2013-04-23 Microsoft Corporation System and method for asynchronous processing in page lifecycle
US8468541B2 (en) * 2007-08-28 2013-06-18 Red Hat, Inc. Event driven sendfile
WO2009033248A1 (en) * 2007-09-10 2009-03-19 Novell, Inc. A method for efficient thread usage for hierarchically structured tasks
US8087022B2 (en) * 2007-11-27 2011-12-27 International Business Machines Corporation Prevention of deadlock in a distributed computing environment
US20110161961A1 (en) * 2009-12-29 2011-06-30 Nokia Corporation Method and apparatus for optimized information transmission using dedicated threads
US8464269B2 (en) * 2010-12-16 2013-06-11 International Business Machines Corporation Handling and reporting of object state transitions on a multiprocess architecture
US9720708B2 (en) * 2011-08-19 2017-08-01 Advanced Micro Devices, Inc. Data layout transformation for workload distribution

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09282189A (ja) * 1996-04-09 1997-10-31 Hitachi Ltd サーバプログラム
JP2002505471A (ja) * 1998-02-26 2002-02-19 サンマイクロシステムズ インコーポレーテッド 遠隔処理の中断および継続の方法と装置
JP2006185229A (ja) * 2004-12-28 2006-07-13 Hitachi Ltd オンライン同期処理方法及び装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014052680A (ja) * 2012-09-05 2014-03-20 Fujitsu Ltd プロセス数制御プログラム、プロセス数制御方法、および情報処理装置
US9329902B2 (en) 2012-09-05 2016-05-03 Fujitsu Limited Information processing method of controlling variation in a number of processes, storage medium, and information processing device
WO2017024965A1 (zh) * 2015-08-11 2017-02-16 阿里巴巴集团控股有限公司 一种数据流量限制的方法及系统
US10560385B2 (en) 2015-08-11 2020-02-11 Alibaba Group Holding Limited Method and system for controlling network data traffic in a hierarchical system

Also Published As

Publication number Publication date
JPWO2012008016A1 (ja) 2013-09-05
US20130132970A1 (en) 2013-05-23
EP2595058A4 (en) 2014-03-12
EP2595058A1 (en) 2013-05-22
JP5408353B2 (ja) 2014-02-05

Similar Documents

Publication Publication Date Title
JP5408353B2 (ja) マルチスレッド処理装置，マルチスレッド処理システム，マルチスレッド処理プログラム，及びマルチスレッド処理方法
US20160315908A1 (en) Method and Apparatus for Managing MAC Address Generation for Virtualized Environments
EP3913859A1 (en) Vnf life cycle management method and apparatus
JP2007122664A (ja) 情報処理方法および情報処理装置
JP2006127461A (ja) 情報処理装置、通信処理方法、並びにコンピュータ・プログラム
JP4407956B2 (ja) 情報処理方法および情報処理装置
CN106897299B (zh) 一种数据库访问方法及装置
WO2016145904A1 (zh) 一种资源管理方法、装置和系统
JP2002505471A (ja) 遠隔処理の中断および継続の方法と装置
WO2017049912A1 (zh) 一种jslee容器的业务处理方法及系统
WO2018196462A1 (zh) 资源调度装置、资源调度系统和资源调度方法
JP2007226800A (ja) 多重ジャバアプリケーション環境で仮想ｉｄを用いて資源を管理する装置およびその方法
JP2009238103A (ja) エージェントを実行する装置及び方法
CN105677481B (zh) 一种数据处理方法、系统及电子设备
JP2020053079A (ja) コンテンツ・デプロイメント、スケーリングおよびテレメトリ
WO2015184902A1 (zh) 一种智能分屏的并发处理方法及相应的智能终端
US11348656B2 (en) Efficient resource sharing
CN112637201A (zh) 一种web服务端的请求处理方法、装置、设备及系统
CN108255820B (zh) 分布式系统中数据入库的方法、装置以及电子设备
WO2014203728A1 (ja) メッセージ制御システム、メッセージ制御装置、メッセージ制御方法及びプログラム
JP2005352689A (ja) 対話型サービス配置方法、対話型サービス配置プログラムおよびその記録媒体、ならびに、サービスブローカ装置
JP6859755B2 (ja) 情報処理装置、情報処理装置の制御方法および情報処理装置の制御プログラム
JP2006185229A (ja) オンライン同期処理方法及び装置
KR101642027B1 (ko) 인터넷 공유 자원에 대한 동기화를 위한 방법 및 장치
KR101632364B1 (ko) 인터넷 공유 자원에 대한 동기화를 위한 방법 및 장치

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: 10854700

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012524359

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010854700

Country of ref document: EP