JP2004265063A - Information processing method and device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a mechanism guaranteeing the issue of a later operation command after the execution of a previously issued operation command in operation executed to shared data shared with a plurality of processes so as to remove restriction on the timing of operation command issue. <P>SOLUTION: In a system wherein each of the plurality of processes holds and uses the shared data shared with the plurality of processes connected via a network, the identity of the shared data held by each the process is maintained. When an operation request to the shared data is generated, an operation event showing the operation request is issued (T2501). By user's prescribed operation, a digestion event is issued (T2503). When an operation event responding to the issued operation event is received from a server, the operation to the shared data is executed according to the operation event. Until a digestion event corresponding to the issued digestion event is received (T2506) after the issue of the digestion event, the issue of the operation event based on the operation request is forbidden. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a technique for sharing data between a plurality of processes. In particular, the present invention relates to a technique suitable for sharing a database holding data describing a three-dimensional virtual space among a plurality of processes via a network.
[0002]
[Prior art]
A technology for sharing a three-dimensional virtual space between different computer terminals is essential for realizing a teleconferencing system, a network-based competitive game, a cooperative design system, and the like.
[0003]
In such a system that shares a three-dimensional virtual space, a large amount of data is referred to at short time intervals in order to draw a moving image in the virtual space by computer graphics. At this time, it is not realistic to acquire the entire data of the virtual space held in one device (for example, a server) via a network due to the narrow bandwidth of the current network. Therefore, a method is adopted in which each terminal has a copy of the virtual space data and generates a CG image by referring to the copy. Also, when a certain operation on a virtual space is performed on a certain computer terminal, for example, movement or rotation of a virtual object, information on the operation is transmitted to another terminal via a network and reflected in a database of each terminal. Is done. As a result, the identity of the database at each computer terminal is maintained.
[0004]
The details of the procedure for maintaining the above-mentioned database identity in a general virtual space sharing system are as follows. That is, an operation on a virtual space in a certain computer terminal is immediately reflected in a local database of the terminal, and the operation information is transmitted to another computer terminal. Other terminals receive the operation information and update data according to the received operation information.
[0005]
An example of realizing such a virtual space sharing system is described in Non-Patent Document 1.
[0006]
However, in a virtual space sharing system represented by Non-Patent Document 1, at the terminal that has performed an operation, the content of the operation is immediately reflected in the database of the terminal, and other terminals receive the operation information, and then receive the operation information. An update is performed. Therefore, the timing at which the database is updated differs between the operated terminal and the other terminals. In particular, if it takes time until the operation information is received due to the influence of traffic on the network or the like, the difference in the timing of updating the database between the terminals becomes remarkable. For this reason, a problem has been pointed out that there is a possibility that a difference occurs in the rendering result of the virtual space between the terminals. In addition, the procedure for operating and updating the database is fixed to the above procedure, and it has been pointed out that it is not possible to select or adjust the data update timing.
[0007]
On the other hand, a system has been proposed in which the timing of executing an operation is substantially the same for a database shared by a plurality of processes. In this system, a server for maintaining the identity of the shared database is provided separately from the terminal, and each terminal issues an operation command for changing the shared database and transmits an event corresponding to the command to the server. On the other hand, the server receives the event transmitted from the terminal, and transmits the event to a plurality of terminals connected to the server. Each terminal updates the database held by the terminal based on the operation information of the event received from the server. That is, since each terminal updates the database held by receiving the event transmitted from the server as a trigger, the timings at which the operations are executed can be made uniform.
[0008]
[Non-patent document 1]
Distributed Open Inventor (exhibitors: G.Heshina et.al.:. "Distributed Open Inventor: A Practical Approach to Distributed 3D Graphics", in Proc of the ACM Symposium on Virtual Reality Software and Technology (VRST'99), pp.74 −81, 1999)
[0009]
[Problems to be solved by the invention]
However, in the above-described system, the timing of executing the operation is almost the same, but after the terminal issues an operation command related to the change of the database, an event corresponding to the operation command spreads to other terminals, and A time lag occurs before the operation is performed on the terminal. In particular, when two or more operations are continuous, an attempt is made to issue a command for a subsequent operation (second operation) at a stage before receiving an event related to the previous operation (first operation) from the server. It can happen. In this case, since the operation result of the first operation has not been reflected in the database yet, the second operation may have an unexpected result. To avoid this, the issuing of the command for the second operation must be delayed.
[0010]
However, the time required from issuance of an operation command to execution of the operation greatly differs depending on the operating environment of the system. Therefore, it is not easy to determine a delay time for delaying the issuance of the command for the second operation, and there is a case where the timing for issuing the operation command is restricted. Therefore, there has been a demand for a mechanism for guaranteeing that the first operation has been executed reliably after issuing the first operation command.
[0011]
The present invention has been made in view of the above problems, and regarding an operation performed on shared data shared by a plurality of processes, an operation instruction issued earlier is executed, and then a subsequent operation instruction is executed. An object of the present invention is to provide a mechanism for guaranteeing that an operation command is issued, and to remove restrictions on the timing of issuing an operation command.
It is another object of the present invention to easily guarantee the operation execution order even when an operation command is issued by a plurality of terminals.
[0012]
[Means for Solving the Problems]
An information processing method according to the present invention for achieving the above object,
In a system in which each of a plurality of processes holds and uses shared data shared by a plurality of processes communicable via an information transmission medium, information for maintaining the identity of the shared data held by each process Processing method,
A first issuing step of, when an operation request for the shared data is issued, issuing an operation event representing the operation request on the information transmission medium;
A second issuing step of issuing an issue prohibition event in response to a predetermined user operation;
An operation execution step of receiving a response operation event in response to the operation event issued by the first issuance step from outside, and executing an operation on the shared data;
After the issuance of the issuance prohibition event in the second issuance step, a prohibition step of prohibiting the issuance of the event in the first and second issuance steps until an event corresponding to the issuance prohibition event is received.
[0013]
An information processing apparatus according to the present invention for achieving the above object has the following configuration. That is,
In a system in which each of a plurality of processes holds and uses shared data shared by a plurality of processes communicable via an information transmission medium, information for maintaining the identity of the shared data held by each process A processing device,
A first issuing unit that issues an operation event indicating the operation request on the information transmission medium when an operation request for the shared data occurs;
Second issuing means for issuing an issue prohibition event in response to a predetermined user operation;
Operation execution means for receiving, from the outside, a response operation event in response to the operation event issued by the first issuing means, and executing an operation on the shared data;
After the issuance prohibition event is issued by the second issuance unit, the prohibition unit prohibits the issuance of the event by the first and second issuance units until an event corresponding to the issuance prohibition event is received.
[0014]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings.
[0015]
[First Embodiment]
In the first embodiment, an embodiment will be described in which the information processing method according to the present invention is applied to a virtual space sharing system in which a scene database describing the structure and attributes of a virtual space is shared by a plurality of terminals.
[0016]
FIG. 1 shows the overall configuration of the virtual space sharing system according to the present embodiment. The system has one server process 101 (hereinafter abbreviated as “server”) and a plurality of client processes 103 (hereinafter abbreviated as “client”), and exchanges data via a network 102 as an information transmission medium. . Each client has a scene database that describes the structure and attributes of a common virtual space. In the present embodiment, the network 102 is a LAN constructed on Ethernet (registered trademark). The information transmission medium may be wireless or wired.
[0017]
Here, the term “database operation” used in the following description will be described. “Operation” of a database refers to a process of rewriting the contents of a database in an arbitrary process having a shared database. The database operation is divided into two stages, "operation command" and "operation execution". The operation command is a request for updating the database, and the actual rewriting is not performed. The actual rewriting of the database is performed at the stage of executing the operation. In the following description, unless otherwise specified, simply describing “operation” indicates “database operation”. If the operation target is other than the database, the operation target is specified, such as “user operation of interactive device”.
[0018]
The operation command may be generated by the user, or may be generated during the operation of the process. As an example of the former, an operation command is generated when a user operates a dialogue device such as a mouse to move a virtual object. On the other hand, as an example of the latter, in a shooting game system, an operation command is generated when a game program algorithmically moves and rotates an enemy character.
[0019]
FIG. 2 shows a basic information flow for updating the database. In FIG. 2, A, B, C, and D (201 to 204) are clients, and X (205) is a server. Now, it is assumed that the client A (201) has issued an operation command for the scene database. The content of the operation command is transmitted to the server via the network (the process indicated by the arrow (1) in FIG. 2). The server receives the operation command and distributes the data transmitted from the client A (201) to all the clients (the process indicated by the arrow (2) in FIG. 2). Through such a process, the clients B (202), C (203), and D (204) of the non-operators can also know the contents of the operation.
[0020]
Next, FIG. 3 shows a configuration of a terminal on which a client or server process operates. In FIG. 3, reference numeral 301 denotes a CPU, which controls the operation of the entire terminal. A memory 302 stores programs and data used for the operation of the CPU 301. Reference numeral 303 denotes a bus, which controls data transfer between the constituent modules. Reference numeral 304 denotes an interface between the bus 303 and various devices. Reference numeral 305 denotes a communication unit for connecting to a network; 306, an external storage device for storing programs and data to be read into the CPU 301; and 307 and 308, input devices for activating the programs and designating the operations of the programs. A keyboard and mouse 309 are a display unit for displaying operation results of the process.
[0021]
The system of this embodiment has the following three modes with respect to the database update timing. Hereinafter, these modes are collectively referred to as “update mode”.
(1) Wait mode (standby mode)
(2) Immediate mode (immediate mode)
(3) Delay mode (delay mode)
Hereinafter, the processing in each mode will be described in detail.
[0022]
The “wait mode” is a mode in which an operation in response to a certain operation command is performed after an event is delivered from the server. FIG. 4 schematically shows a processing procedure along the progress of time in the wait mode. In FIG. 4, “operator” indicates a client that has issued an operation command, and “non-operator” indicates a client other than the operator. The progress of the process is as described below.
[0023]
First, in step T401, the operator client issues a database operation command. At this point, the operator client database is not updated. Next, in step T402, an event indicating the operation content of T401 is generated, and transmitted to the server in T403. The server receives the event in step T404, and transmits the event to all clients that have established a connection with the server in T405 (connection establishment will be described later in step S1102 of FIG. 11). The operator client receives the event issued from the server in step T406, analyzes the content (T407), and rewrites the database (T408). The procedure from the reception of the event is the same for the non-operator client (procedures T409 to T411). As shown in FIG. 4, in the wait mode, there is a time lag from the operation command (T401) to the operation execution (T408). However, if the conditions of the information transfer on the network are the same, it is expected that the database is updated at substantially the same time for both the operator and the non-operator clients, and that the images in the virtual space are synchronized between the clients.
[0024]
In the "immediate mode", a command from the operator is immediately reflected in the database, while the database of the non-operator is updated with a delay. FIG. 5 schematically shows a processing procedure along time progress in the immediate mode. The progress of the process is as described below.
[0025]
First, in step T501, the operator client issues a database operation command. Next, in step T502, the database is updated according to the contents of the operation command. Thereafter, an event indicating the operation content is generated (T503) and transmitted to the server (T504). After transmitting the event, the operator client holds, as an operation queue, information indicating that the operation command and execution of the procedure T501 have been performed (T505, “operation queue” will be described later).
[0026]
The server receives the event in procedure T506, and transmits the event to all clients in T507. Upon receiving the event from the server in step T508, the operator client refers to the operation queue (T509). Here, since the information recorded in step T505 recognizes that the operation has already been executed, the operation execution processing is not performed, and the information recorded in step T505 is deleted (T514).
[0027]
On the other hand, the non-operator client recognizes that the event received in step T510 is not executed by referring to the operation queue (T511), and executes an operation based on the content of the event (T512, T513).
[0028]
When the database is updated according to the above procedure, the time delay until the result of the operation on the virtual space is reflected on the CG image in the operator client is smaller than in the wait mode. Therefore, the immediate mode is suitable mainly when the user operates the virtual object using the interactive device. This is because in general, if a time lag occurs between the interactive operation of the user and the presentation of the result, problems such as more difficult operation and discomfort to the user occur.
[0029]
In the “delay mode”, an operation command is not immediately executed as in the wait mode, but an operation execution time limit is provided, and when the time limit has passed, the operation is executed without waiting for an event response from the server. Things. FIG. 6 schematically shows a processing procedure along the progress of time when an event arrives from the server before the operation execution deadline is reached in the delay mode. The progress of the process is as described below.
[0030]
First, in step T601, the operator client issues a database operation command. At this point, the database is not updated. Next, in step T602, an event indicating the content of the operation of T601 is generated, and transmitted to the server in T603. After the event transmission, the operator client holds information indicating that the operation command of the procedure T601 has been performed in the operation queue (T604, “operation queue” will be described later), and starts timer processing (T605). The timer process executes the operation after waiting for a timeout, and the details will be described later with reference to FIG.
[0031]
On the other hand, the server receives the event in step T606, and transmits the event to all clients in T607. The operator client receives the event in step T608, and refers to the operation queue (T609). Here, since it is recognized that the operation has not been executed, the fact that the operation has been executed is recorded in the operation queue (T610), the contents of the event are analyzed (T611), and the database is rewritten (T612). . Further, the information recorded in T604 is deleted (T617). Further, the non-operator client recognizes that the event received in step T613 has not been executed (T614), and executes an operation based on the content of the event (T615, T616).
[0032]
On the other hand, FIG. 7 schematically shows a processing procedure along the progress of time when an operation execution time limit (timeout) is reached before an event from the server arrives in the delay mode. The progress of the process is as described below.
[0033]
First, in step T701, the operator client issues a database operation command. At this point, the database is not updated. Next, in step T702, an event indicating the content of the operation of T701 is generated, and transmitted to the server in T703. After transmitting the event, the operator client holds information indicating that the operation command of the procedure T701 has been performed in the operation queue (T704, “operation queue” will be described later), and starts timer processing (T705). Note that the timer process performs an operation execution after a timeout, and details will be described later with reference to FIG. On the other hand, the server receives the event in step T706, and transmits the event to all clients in T709.
[0034]
In the timer processing, when a time-out time arrives before a corresponding event is received from the server, the timer processing detects the time-out, and executes the operation in step T707, and the operation is executed in the operation queue. Is stored (T708). Therefore, the operator client later receives the event in step T710, but recognizes that the operation has been executed by referring to the operation queue (T711), and does not execute the operation. The non-operator client recognizes that the event received in step T713 has not been executed (T714), and executes an operation based on the content of the event (T715, T716).
[0035]
When the database is updated according to the above procedure, the operation is performed so that the operation execution is not delayed as much as possible if the time lag of the event distribution is large, and the operation is performed so as to synchronize the clients if the time lag is small. Such switching of the operation is automatically performed, and it is possible to adjust which operation is dominant by appropriately setting the timeout time.
[0036]
In the present embodiment, with respect to the above-described wait mode and delay mode, processing corresponding to the digestion event mode and the synchronous event mode is further executed in order to guarantee the order of operation execution and operation command issuance. These will be described later.
[0037]
FIG. 8A shows the contents of an event issued from the client to the server or from the server to the client. The event data is composed of a plurality of fields. The client ID 801 is a number for uniquely identifying each client, and is assigned by the server when the client establishes a network connection with the server (described later in step S1102 in FIG. 11). The operation ID 802 is a number for uniquely identifying an operation, and is assigned when an operation command is issued to each client. By using the set of the client ID 801 and the operation ID 802, it is possible to uniquely specify all operation commands that have occurred in the system.
[0038]
The update mode ID 803 is an identification number uniquely determined for each update mode, and is determined according to the update mode of the operation command corresponding to this event. The update mode is set and registered in each entry of the database (described later with reference to FIG. 21), and the update mode is set with reference to this. Any one of the wait mode, delay mode, and immediate mode described above is set as the update mode ID 803.
[0039]
The timeout time 804 is used in the above-described delay mode, and describes a time obtained by adding a delay time to an event occurrence time. The entry ID 805 is a number for uniquely identifying each entry of the database, and is assigned when data is loaded from a file. The operation content 806 is a specific content of the operation command. For example, if the operation is to set the X coordinate of the CG object to a certain value, the operation content 806 is represented by a set of a number for identifying the X coordinate attribute and an X coordinate set value. .
[0040]
FIG. 8B shows the data structure of the synchronization event and the digestion event. This event includes a client ID 811 and an event type 812 indicating the type of event (digestion or synchronization).
[0041]
Next, the operation queue will be described. The operation queue is a list of operation commands waiting for an event reception or execution process. Assuming that there are m operation commands in a standby state at a certain point in time, the operation queue has m pieces of information (queue items) related to the operation commands arranged in the order of generation of the commands as shown in FIG.
[0042]
The content of one queue item is composed of three data fields as shown in FIG. The operation ID 1001 is a number for uniquely identifying an operation, and has the same value as the operation ID field of the corresponding event. The operation ID 1001 is assigned when an operation command is issued in the client. The timeout time 1002 is an operation execution time limit in the delay mode, and is obtained by adding a predetermined timeout time to the current time when an operation command is issued in the client. The executed flag 1003 indicates whether the operation having this operation ID has been executed in the immediate mode or the delay mode. The executed flag is set to OFF when the operation command is issued, and is changed to ON when the operation is executed.
[0043]
In FIG. 10A, an operation queue item having three fields is shown, but it is also possible to use both the executed flag and the timeout time. In this case, when the timeout time is a special value (for example, minus one), it may be defined as being already executed. The data configuration of the operation queue item in this case is as shown in FIG.
[0044]
Next, event digestion and event synchronization will be described. The user can cause the terminal to issue digestion events and synchronization events at desired timing.
[0045]
First, the event digestion will be described. In the case of the wait mode or the delay mode, a time lag occurs between the time when the operator client issues an operation command and the time when the operation is executed. For example, it is assumed that there are first and second consecutive two operations, and the second operation is performed only when the first operation result satisfies a certain condition. After the first operation command is issued, if the second operation command is issued in a state where the first operation has not been executed, the first operation result is not reflected in the database at that time. There is a possibility that the result of the first operation cannot be correctly referred to and the second operation cannot be performed correctly. Therefore, after the first operation command is executed, it is necessary to wait until the first operation command is executed, and then issue the second operation command. That is, before the second operation command, it is necessary to keep all the events that have been issued before that and have not been executed yet in the executed state. Hereinafter, setting all events issued up to the present time to the executed state is referred to as “digesting events”.
[0046]
Hereinafter, processing of the digestion event in the wait mode will be described. FIG. 22 shows the procedure of event digestion. In FIG. 22, two clients are connected to one server. First, in step T2501, the client 1 issues a database operation command, and an operation event indicating the operation content is transmitted to the server. At this point, the operation result of the procedure T2501 is not reflected in the database of the client 1. In step T2502, the server receives the operation event 1, and transmits the operation event 1 to the client 1 and the client 2.
[0047]
On the other hand, in the client 1, the user instructs the issuance of the digestion event prior to the input of the operation command 2 affected by the operation execution result of the operation command 1. This operation is for ensuring that the operation command 2 is issued after the operation of the operation command 1 is performed. In response to this instruction, a “digestion event” is generated in step T2503, transmitted to the server, and the issuance of the operation command is stopped (the operation command issuance is stopped).
[0048]
In step T2504, the server receives the digestion event and transmits the digestion event to the client 1 and the client 2. At this time, the server treats the digestion event in the same manner as a normal operation event. That is, the received digestion event is transmitted to all the clients that have established a connection, including the transmission source.
[0049]
By the way, even if the client 1 attempts to issue the operation command 2 in the procedure T2505, the operation command 2 is not issued at this time because the operation command issuance has already been stopped in the procedure T2503. At this time, the operation command 2 is added to an operation command issuance queue (not shown) (the “operation command issuance queue” will be described later).
[0050]
The client 1 executes the operation immediately upon receiving the operation event 1 from the server. Upon receiving the digestion event transmitted from the server in step T2506, the client 1 refers to the client ID 801 (FIG. 8) in the digestion event data. As a result, when the received digestion event has been transmitted by the client 1, the suspension of the operation command issuance is released. When the suspension of the operation command issuance is canceled, the operation commands registered in the operation command issuance queue are sequentially issued with reference to the operation command issuance queue (step T2507). In the case of FIG. 22, the operation command 2 instructed in T2505 is issued, and the operation event 2 is transmitted to the server. In the procedure T2508, the client 2 receives the digestion event. However, since this digestion event is not transmitted by the client 2, it is discarded as it is.
[0051]
As described above, if a digestion event is issued (sent to the server) from the same client after issuing an operation command, after the digestion event is transmitted, the operation command is issued until the issued digestion event is received from the server. To stop. By doing so, it is possible to issue the next operation command after ensuring that the previous operation command has been executed.
[0052]
When the update mode is the immediate mode, the operation command is issued immediately after being issued, so that the event digestion procedure need not be performed.
[0053]
Further, when the update mode is the delay mode, after the operation command issuance is stopped in step T2503, if the timeout time is reached before the digestion event is received from the server, the operation command issuance suspension is released at that time, The registered event is issued by referring to the operation command issuance queue. If the operation has not been performed at this time, the operation is immediately performed as described above for the delay mode.
[0054]
Next, event synchronization will be described. By synchronizing events, the order of operation is guaranteed for all connected clients. There is a time lag from the issuance of the operation command of the operator client to the execution of the operation of the non-operator client. For example, when there are two first and second consecutive operations, the first operation command is issued by the client 1, the second operation command is issued by the client 2, and the first operation result satisfies a certain condition. Only the second operation is performed. Now, suppose that after the client 1 issues the first operation command, the second operation command is issued on the client 2 in a state where the first operation has not been executed. In this case, since the first operation is not reflected in the database of the client 2 at that time, the first operation result cannot be correctly referred to on the client 2 and the second operation may not be performed correctly. . As a result, the contents of the database differ between the clients, and there is a possibility that matching cannot be achieved.
[0055]
Assuming that the first operation has been executed in the client 1 and not executed in the client 2 at the time when the second operation command is issued on the client 2, the second operation is correctly executed in the client 1. However, the second operation is not executed correctly on the client 2. Therefore, the client 2 must wait until the first operation is performed on all the clients, and then issue the second operation command. That is, before the second operation command, it is necessary to digest all the events that have been issued by all the clients and have not been executed before that, and synchronize the events issued after that among all the clients. . In the present embodiment, this is realized by issuing and managing a synchronization event.
[0056]
FIG. 23 shows the procedure of event synchronization. In FIG. 23, two clients are connected to one server, client 1 performs operation 1, and client 2 performs operation 2 that is affected by the execution result of operation 1. It is assumed that the user knows in advance that the operation 2 performed by the client 2 is an operation affected by the operation 1 performed by the client 1. FIG. 23 shows a state in which the event issuance of the client 1 and the client 2 is synchronized.
[0057]
First, in step T2601, the client 1 issues a database operation command, and an event indicating the operation content is transmitted to the server. At this point, the operation result of the procedure T2601 is not reflected in the database of the client 1, and the operation is executed when the operation event 1 is received from the server 1 thereafter.
[0058]
In step T2602, the server receives the operation event 1, and transmits the operation event 1 to the client 1 and the client 2. Here, since the operation command 1 is accompanied by the operation command 2 affected by the operation result, the user of the client 1 performs an operation for issuing a synchronization event. By this operation, in a procedure T2603, "synchronous event 1" is generated and transmitted to the server. Then, the issuance of the operation command in the client 1 is stopped. The suspension of the issuance of the operation command is released when a synchronization event of the number of clients is received from the server.
[0059]
In step T2604, the server receives the synchronization event 1 transmitted by the client 1, and transmits the synchronization event 1 to the client 1 and the client 2. At this time, the server treats the synchronization event as a normal operation event. When the client 2 receives the operation event, it executes this.
[0060]
On the other hand, the user of the client 2 intends to issue the operation command 2 that is affected by the operation execution result of the operation command 1, and performs an operation of issuing a synchronization event to synchronize the system. In a procedure T2605 in FIG. 23, the synchronization event 2 is generated by this operation and transmitted to the server. The issuance of the operation command in the client 2 is stopped along with the issuance of the synchronization event. This ensures that the operation command 2 is issued after the operation command 1 has been executed by the previous client.
[0061]
When the client 1 receives the operation event 1 transmitted from the server, the corresponding operation is executed. In step T2606, the synchronization event 1 is received. At this point, since only one synchronization event has been transmitted by the client 1, transmission of the operation command is stopped.
[0062]
The client 2 also receives the synchronization event 1 in the procedure T2607. At this point, since only one synchronization event has been received so far, the suspension of issuing the operation command is continued. Therefore, even if the client 2 attempts to issue the operation command 2 in the procedure T2608, the operation command 2 is not issued at this time because the operation command issuance is stopped in the procedure T2605. At this time, the operation command 2 is added to an operation command issuance queue (not shown) in the client 2.
[0063]
In step T2609, the server receives the synchronization event 2 issued by the client 2, and transmits the synchronization event 2 to the client 1 and the client 2. In step 2610, the client 1 receives the synchronization event 2 transmitted from the server. At this point, a total of two synchronization events transmitted by the client 1 and the client 2 have been received, which is equal to the number of clients connected to the server, so that the suspension of issuing the operation command is released. When the suspension of the operation command issuance is canceled, the operation command issuance queue is referred to, and if there is an operation command registered in the operation command issuance queue, this is processed (issued).
[0064]
Similarly, in step T2611, the client 2 receives the synchronization event 2 transmitted from the server. Since two synchronization events have been received in the client 2, the suspension of issuing the operation command is released in the same manner as in the procedure T2610. Then, in step T2612, the client 2 refers to the operation command issuing queue and issues the operation command registered in the queue. In this case, the operation command 2 is issued, and the operation event 2 is transmitted to the server.
[0065]
As described above, in the synchronous event mode, all clients issue synchronous events, and each client receives synchronous events issued by each client for the number of clients (via the server). Each client stops issuing operation commands until reception of all synchronization events is completed. By doing so, when the reception of the synchronization event is completed, all the operation commands issued by all the clients so far are reliably consumed.
[0066]
Note that the synchronization event is issued by a user's operation instruction, and each client constantly counts the number of synchronization events received from the server. When the count value reaches a predetermined number (here, the number of clients that have established a connection with the server), the suspension of the issuance of the operation command is released, the count value is reset, and the count of the synchronization event is counted again. To start.
[0067]
However, when the update mode is the delay mode, if the time-out time has come without completing the reception of the synchronization event from all the clients, the suspension of the operation command issuance is released at that time.
[0068]
Further, it is not always necessary to synchronize all clients connected to the server, and a group of clients to be synchronized may be arbitrarily set. For example, when composing the data of the synchronization event, the client identification number of the client group to be synchronized is set in the operation content 806 (FIG. 8). When each client receives the synchronization event, the client ID number set in the operation content 806 is compared with the number described in the client ID 811 (FIG. 8B) of the synchronization event, and the operation content 806 is received. When the synchronization event has been received from the client with all the client identification numbers set in, the suspension of issuing the operation command is released. By doing so, it is possible to synchronize event issuance between arbitrary clients.
[0069]
Next, the operation command issuance queue will be described. The operation command issuance queue is a list of operation commands waiting to issue an event, and has the same configuration as the operation queue shown in FIG. That is, assuming that there are m operation commands in a standby state at a certain time, the operation command issuance queue has m pieces of information (queue items) related to the operation commands arranged in the order of command issuance as shown in FIG. The operation queue and the operation command issuance queue are a list of operation commands in which the former is waiting for the reception or execution of an event, while the latter is a list of operation commands in which the event is waiting to be issued. Although there is such a difference, since both are lists for storing operation commands, the operation command issuance queue can be realized with the same means and configuration as the operation queue.
[0070]
Next, the flow of the above-described processing for each of the client and the server will be described in detail.
[0071]
FIG. 11 shows the overall flow of the client process. When the client is started, a file describing the virtual space is read from the external storage device 306 (FIG. 3) in step S1101, and a scene graph database is constructed on the memory 302 (FIG. 3). It is assumed that the file to be loaded has the same contents between the clients in order to maintain the data consistency between the clients. Next, a network connection with the server is established (step S1102). At this time, a client ID for identifying each client is assigned from the server. The data exchange between the client and the server is performed by one-to-one socket communication using the TCP / IP protocol. Therefore, the server has at least as many socket communication paths as the number of clients.
[0072]
Subsequently, the process branches in step S1103, and an operation process for processing an operation command (step S1104) and a reception event process for processing an event received from the server (step S1106) are started. Although not shown in FIG. 11, a process of generating a CG image of the virtual space with reference to the scene graph database is also started. This process is the same as a known CG image generation method, and a detailed description thereof will be omitted. The operation process and the reception event process will be described later in detail. In the operation processing and the reception event processing, it is determined in step S1105 and step S1107 whether there is an instruction to end the process. If there is no instruction to end, the process returns to step S1104 and step S1106 to continuously process the operation instruction and the reception event. On the other hand, if there is a termination instruction, the processes are integrated in step S1108, the network connection with the server is disconnected (step S1109), and the contents of the database are saved as a file in the external storage device (306 in FIG. 3) (step S1110). ) And end all the processing.
[0073]
Here, the operation processing of step S1104 will be described in detail with reference to FIGS. 12A and 12B. First, the contents of the operation command are input in step S1201. In the present embodiment, when an operation instruction is input from a user other than when the operation instruction is not being issued, the process corresponding to the operation instruction is immediately executed. If the processing is performed, the processing is temporarily registered in the operation command issuance queue, and the process is executed after the suspension of the operation command issuance is released.
[0074]
FIG. 12B is a flowchart illustrating in detail a process corresponding to step S1201 in FIG. 12A. When an operation instruction is given while the operation instruction issuance is stopped, the operation is registered in the operation instruction issuance queue (steps S1220, S1221, and S1222). On the other hand, when the operation instruction is issued while the operation instruction is not being suspended, it is determined whether the operation instruction is an instruction to issue a digestion event or a synchronization event. If none of the digestion / synchronization events, the process proceeds to step S1202 (FIG. 12A). If the operation instruction is any of the digestion / synchronization events, the process advances to step S1226 to issue the corresponding event (digestion event or synchronization event as shown in FIG. 8B) and shift to the operation command issue suspension state. I do.
[0075]
If an operation instruction has not been issued in step S1223, the process advances to step S1224 to determine whether there is an unprocessed operation instruction in the operation instruction issuance queue. If there is an unprocessed operation instruction, the process advances to step S1225 to perform the same processing as described above. If there is no operation command issuance queue in step S1224, the process returns to step S1220 to repeat the above processing.
[0076]
Returning to FIG. 12A, in steps S1202 and S1203, the update mode is determined with reference to the database entry. In accordance with the update mode, the process ends after performing any one of the wait mode operation process in step S1206, the immediate mode operation process in step S1205, and the delay mode operation process in step S1204.
[0077]
Hereinafter, the operation processing (steps S1204, S1206) for each update mode will be described in detail with reference to FIGS.
[0078]
FIG. 13 shows the flow of the wait mode operation process. In the wait mode operation process, first, an operation event corresponding to the operation command is generated in step S1301, and the operation event is issued in step S1302.
[0079]
The flow of the immediate mode operation processing is as shown in FIG. First, in step S1401, the operation command input in step S1201 is executed. Specifically, the setting value of the designated entry of the database is changed. Next, similarly to the wait mode, an event is generated (step S1402), and the event is transmitted to the server (step S1403). In the last step S1404, the operation ID is set to the operation ID number determined in step S1201, the executed flag is set to ON, and the set operation queue items are added to the operation queue. At this time, since the timeout time is not used for the processing, it may be set arbitrarily (for example, 0).
[0080]
Next, the delay mode operation processing will be described with reference to FIG. First, an event is generated as in the wait mode (step S1501), and transmitted to the server (step S1502). Next, the operation queue item is set by setting the operation ID 1001 to the operation ID number determined in step S1201, the timeout time 1002 to a value obtained by adding a predetermined timeout period to the current time, and setting the executed flag to OFF (FIG. 9). Is added to the operation queue (step S1503). Finally, the timer process is started by passing data of the operation ID, the operation content, and the time-out time (step S1504). The timer process will be described later in detail.
[0081]
Subsequently, the reception event processing in step S1106 (FIG. 11) will be described in detail. FIG. 16A is a diagram showing the flow of the reception event process. The reception event is received by the event communication unit (not shown) from the server, and is input to the reception event buffer.
[0082]
In step S1601, a reception event buffer is searched. In a succeeding step S1602, it is determined whether or not an event has been input to the reception event buffer, and if there is a reception event, the process proceeds to step S1603. On the other hand, if it is determined that there is no reception event, the process ends.
[0083]
If there is a received event, the event data is analyzed and the contents of the operation command are extracted (step S1603). Next, in step S1611, it is determined whether the event is a digestion event or a synchronization event. If the event is a digestion event or a synchronization event, the process advances to step S1612 to perform a corresponding process. On the other hand, if the event is neither the digestion event nor the synchronization event, the update mode of the operation command is determined with reference to the event update mode ID 803 in steps S1604 and S1605. Then, according to the determined update mode, the processing ends after passing through any one of steps S1608 (in the case of the wait mode), step S1606 (in the case of the immediate mode), and step S1607 (in the case of the delay mode).
[0084]
Next, the digestion / synchronization event processing in step S1612 will be described. FIG. 16B is a flowchart illustrating the digestion / synchronization event processing. In step S1621, it is determined whether the event is a digestion event issued by itself. This can be determined by referring to the client ID 811 and the event type 812 shown in FIG. If it is the digestion event issued by itself, the flow advances to step S1622 to cancel the suspension of the operation command issuance.
[0085]
On the other hand, if it is not the digestion event issued by itself, it is determined in step S1623 whether the event is a synchronous event. If it is a synchronous event, the synchronous event is counted in step S1624, and it is determined whether or not the count value has reached a predetermined number (step S1625). If the number has reached the predetermined number, the flow advances to step S1627 to clear the count of the synchronization event and cancel the suspension of operation command issuance (step S1628). If the count value of the synchronization event is not the predetermined number, the process ends.
[0086]
Next, event processing in each update mode will be described. In step S1608, since the mode is the wait mode, the operation process corresponding to the operation event is immediately executed.
[0087]
The immediate mode event processing in step S1606 will be described with reference to FIG.
[0088]
FIG. 17 shows the flow of the immediate mode event process. First, an operation queue is searched in step S1701, and it is determined in step S1702 whether an operation queue item corresponding to the received event exists in the operation queue. Specifically, if the client ID of the received event matches the ID of the client on which the process is operating, and the operation ID of the received event matches the operation ID of the operation queue item, the operation command of the operation queue item is issued. And the operation command of the reception event are determined to correspond. In the immediate mode, if a corresponding queue item exists, it has been executed when the operation was generated by the client. Therefore, the operation is not executed here, the operation queue entry is deleted in step S1703, and the process ends. On the other hand, if it is determined in step S1702 that there is no corresponding queue item, the operation has not been executed yet because the operation was generated by a client other than the client. Therefore, the operation is executed in step S1704, and the process ends.
[0089]
The flow of the delay mode event process in step S1607 is as shown in FIGS. 18A and 18B.
[0090]
First, an operation queue is searched in step S1801, and it is determined in step S1802 whether an operation queue item corresponding to the received event exists in the operation queue. Details of the processing in step S1802 are the same as those in step S1702. Here, when the corresponding operation queue item does not exist, it is understood that the operation event is issued from another client. In this case, the operation has not been executed yet because it was generated by a client other than the client. Therefore, the process proceeds to step S1804, and the operation is executed. The processing in step S1804 will be described later with reference to FIG. 18B.
[0091]
On the other hand, if an operation queue item corresponding to the operation queue exists in step S1802 in FIG. 18A, it is an operation event issued by itself. In this case, the process proceeds to step S1803, and the executed flag of the operation queue item is checked. If the executed flag is ON, the timeout event has passed, and the operation event has been executed by the timer process (described later). Therefore, the operation is not performed here, and the operation queue entry is deleted in step S1805.
[0092]
FIG. 18B is a flowchart for explaining a difference process of executing a command mode operation event issued from another client. First, in step S1820, the operation event is executed. Then, in a step S1821, it is determined whether or not the user himself / herself is currently stopping issuing the operation command. If the issuance of the operation command is not stopped, the process ends.
[0093]
If the operation command is not being issued, the process advances to step S1822 to determine whether a timeout has occurred. Here, the determination of the timeout can be made by referring to the timeout time 804 included in the operation event. If not, the process returns to step S1821. If the count value of the synchronization event has reached the predetermined number before the timeout occurs, the process ends from step S1821 as it is. On the other hand, if the timeout occurs before the count value of the synchronization event reaches the predetermined number, the process proceeds from step S1822 to step S1823, and the suspension of the operation command issuance is released.
[0094]
On the other hand, if it is determined in step S1803 that the executed flag is OFF, the operation has not been executed since the timeout time has not yet been reached. Therefore, the operation is immediately executed in step S1806, and the item is deleted from the operation queue in step S1805.
[0095]
Next, the timer process started in step S1504 of FIG. 15 will be described in detail with reference to FIG. This is a process for coping with a case where the timeout time has been reached in the delay mode.
[0096]
First, an operation queue is searched in step S1901, and it is determined in step S1902 whether an operation queue item corresponding to the operation specified when the timer process was started exists. Specifically, if the operation ID, which is an argument at the time of starting this process, matches the operation ID of the operation queue item, it is determined that the operation command of the operation queue item and the operation command specified by the argument correspond to each other. . When the corresponding queue item exists, it means that the reception event corresponding to the operation command has not been processed, that is, has not been executed. In this case, the process proceeds to a process for checking whether or not the timeout time has been reached. That is, the current time is referred to in step S1903, and the order of the current time is determined (step S1904). If the time-out time has passed, the operation is executed in step S1905, and the executed flag of the corresponding operation queue item is set to ON. Further, the suspension of the operation command issuance is released.
[0097]
On the other hand, if the time has not reached the timeout time, the process returns to step S1901. If it is determined in step S1902 that the corresponding operation queue item does not exist, it means that the reception event corresponding to the operation command has been processed, that is, the operation has been executed. In this case, since there is no need to execute an operation or change the operation queue, the process ends.
[0098]
The flow of the client-side process has been described above. Subsequently, the flow of the server-side process will be described in detail with reference to FIG.
[0099]
First, in step S2001, a connection request from a client is received and communication is established. At this time, a client ID is notified to each client that has established communication. Next, the reception event buffer is searched (step S2002), and it is determined whether a reception event exists (step S2003). If there is a reception event, the process proceeds to step S2004; otherwise, the process proceeds to step S2005. In step S2004, the event (operation event, digestion event, synchronization event) is transmitted to each connected client. In step S2005, it is determined whether or not to end the server process in response to a command from the user or the like. If the server process is to be ended, the process proceeds to step S2006; otherwise, the process returns to step S2002. In step S2006, each connected client is notified of the end of the processing, and then the connection with the client is ended (step S2007), and the processing ends.
[0100]
Next, the configuration of the database description file read by the client in the present embodiment will be described.
[0101]
FIG. 21 schematically shows a file format of data having N entries. The attribute of each entry is described in a field surrounded by a start delimiter and an end delimiter. In FIG. 24, the start delimiters of the first, second, and Nth entries are indicated by 2401, 2406, and 2409, respectively. On the other hand, the respective end delimiters are 2405, 2408, and 2411. The attribute of the entry is described as a set of an identifier for identifying each attribute and an attribute value, such as 2402 to 2404. The update mode (including the digestion / synchronization event mode) and the timeout period are specified for each entry in a file in the above format. However, when the update mode of the entry is not the delay mode, the timeout time need not be described. In both update modes, it is not always necessary to describe both attributes. If there is no description, the system determines in advance when a scene graph database is constructed on the memory (302 in FIG. 3) (step S1101). Is set to the specified default value.
[0102]
In the database description file described above, the update mode to be selected is described. On the other hand, one or more update modes that cannot be selected can be set.
[0103]
In the above description, the data communication between the server and the client is performed using a one-to-one TCP / IP socket. However, events may be exchanged by broadcast or multicast, and the communication protocol is TCP / IP. Not exclusively.
[0104]
In addition, although Ethernet (registered trademark) is used as a communication medium, another information transmission medium such as USB or Firewire may be used. Further, the form of the network is not limited to the LAN, but may be a connection via a WAN or a combination of the LAN and the WAN.
[0105]
The number of servers does not need to be limited to one for one shared database system, and a plurality of servers may exist. In this case, the mode of assigning the process to each server is arbitrary. For example, a different server may be used for each client, or a server may be provided for each entry in the database.
[0106]
Furthermore, the assignment of processes to terminals is not limited to one process per terminal, and a plurality of processes can be operated on one terminal. In that case, the combination of the process types is arbitrary, and the system operates with any combination of only the client, only the server, and the client and the server. The processes on the same terminal may exchange data via a shared memory instead of the network.
[0107]
Further, the event is distributed to each terminal through the server, but the terminal that has performed the data operation may directly transmit the event to another terminal.
[0108]
Further, in the above description, the three-dimensional virtual space data is shared, but it goes without saying that the contents of the database are not limited to this and are arbitrary. Further, it goes without saying that the method described in the above embodiment can be applied not only when the entire database is shared but also when only a part of the database is shared.
[0109]
As described above, according to the present embodiment, each of the plurality of processes holds shared data (database) shared by a plurality of processes (client processes) communicably connected via the information transmission medium. An information processing method for maintaining the identity of shared data held by each process in a system to be used is disclosed. In particular, when an operation request for the shared data occurs, request information (event) representing the operation request is output on the information transmission medium, and response information (event) to the request information is received from the information transmission medium. Perform an operation on the shared data according to the received response information. According to such a wait mode, the operation on the shared data is performed according to the event received via the information transmission medium, so that the update timing of the shared data can be matched with high accuracy.
[0110]
In the delay mode, if a predetermined time has elapsed from the generation of the operation request before receiving the response information, the operation of the shared data based on the operation request without waiting for the reception of the response information is performed by the timer processing. Be executed. For this reason, it is possible to achieve both responsiveness in the process in which the operation has occurred and matching of the synchronization timing between the plurality of processes.
[0111]
Further, according to the present embodiment, a queue item is registered in an operation queue in response to an operation request, and queue control is performed to set a corresponding queue item to a processed state when an operation on shared data is performed in an operation execution step. When the item corresponding to the operation request represented by the response information has not been processed in the operation queue, the operation corresponding to the response information is executed on the shared data. In the delay mode as described above, duplication of operation execution can be prevented with a simple configuration.
[0112]
Further, according to the present embodiment, the first mode (wait mode) in which the operation of the shared data is executed after waiting for the response information to be received in the receiving step, the elapse of a predetermined time from the generation of the operation request, It is possible to operate in any of a plurality of change modes including a second mode (delay mode) in which the operation of the shared data is performed at the earlier timing of receiving the response information.
[0113]
The shared data is composed of a plurality of items (FIG. 21), and each of the plurality of items includes designation information for designating a change mode to be adopted. The change mode is selected according to the specified information, and the operation on the shared data is executed. That is, the change mode is switched for each of a plurality of items. According to this configuration, an appropriate change mode can be set for each item.
[0114]
According to the present embodiment, when the same client issues two or more consecutive operation commands, after issuing the previous operation command, the operation command issued later refers to the execution result of the previous operation command. Even in such a situation, it is possible to appropriately execute all operations and reflect the operations in the database.
[0115]
Further, according to the present embodiment, when issuing a continuous operation command among a plurality of clients, after issuing the previous operation command on a certain client, a client different from the client that issued the previous operation command is issued. Even if the operation command issued later refers to the execution result of the previous operation command, all operations should be executed properly on all clients and properly reflected in the database of all clients Is possible.
[0116]
Further, in a server process, in a system in which each of the plurality of processes holds and uses shared data shared by a plurality of processes connected via the information transmission medium, the same shared data held by each process is used. In order to maintain the reliability, a connection with a plurality of client processes is established, and an event related to a change of shared data is received from the plurality of client processes. Then, the received event is issued to the plurality of client processes.
[0117]
It is to be noted that an object of the present invention is to provide a storage medium storing a program code of software for realizing the functions of the above-described embodiments to a system or an apparatus, and a computer (or CPU or MPU) of the system or apparatus to store the storage medium. It is needless to say that the present invention is also achieved by reading and executing the program code stored in
[0118]
In this case, the program code itself read from the storage medium realizes the function of the above-described embodiment, and the storage medium storing the program code constitutes the present invention.
[0119]
As a storage medium for supplying the program code, for example, a flexible disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a magnetic tape, a nonvolatile memory card, a ROM, and the like can be used.
[0120]
When the computer executes the readout program code, not only the functions of the above-described embodiments are realized, but also an OS (Operating System) running on the computer based on the instruction of the program code. It goes without saying that a part or all of the actual processing is performed and the functions of the above-described embodiments are realized by the processing.
[0121]
Further, after the program code read from the storage medium is written into a memory provided on a function expansion board inserted into the computer or a function expansion unit connected to the computer, the function expansion is performed based on the instruction of the program code. It goes without saying that a CPU or the like provided in the board or the function expansion unit performs part or all of the actual processing, and the processing realizes the functions of the above-described embodiments.
[0122]
【The invention's effect】
As described above, according to the present invention, for an operation performed on shared data shared by a plurality of processes, a previously issued operation command is executed, and then a subsequent operation command is issued. This provides a mechanism for ensuring that the operation command is issued, and removes restrictions on the timing of issuing operation commands.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration of an entire database sharing system according to a first embodiment.
FIG. 2 is a diagram showing a basic method of transmitting information between processes according to the first embodiment.
FIG. 3 is a block diagram illustrating a hardware configuration of the terminal device according to the first embodiment.
FIG. 4 is a diagram showing a database update procedure in a wait mode.
FIG. 5 is a diagram showing a procedure for updating a database in an immediate mode.
FIG. 6 is a diagram illustrating a database update procedure in a delay mode (when no timeout occurs).
FIG. 7 is a diagram showing a procedure for updating a database in a delay mode (at the time of timeout).
FIG. 8 is a diagram illustrating a data configuration example of event data.
FIG. 9 is a diagram illustrating an example of a data configuration of an operation queue.
FIG. 10 is a diagram illustrating a data configuration example of an operation queue item.
FIG. 11 is a flowchart of a client process according to the first embodiment.
FIG. 12A is a flowchart showing operation processing in a client process.
FIG. 12B is a flowchart illustrating the operation input processing of FIG. 12A.
FIG. 13 is a flowchart illustrating a wait mode operation process of FIG. 12A.
FIG. 14 is a flowchart illustrating an immediate mode operation process of FIG. 12A.
FIG. 15 is a flowchart illustrating a delay mode operation process of FIG. 12A.
FIG. 16A is a flowchart showing a reception event process in the client process of FIG. 11;
FIG. 16B is a flowchart showing the digestion / synchronization event processing of FIG. 16A.
FIG. 17 is a flowchart of an immediate mode reception event process of FIG. 16A.
FIG. 18A is a flowchart of a delay mode reception event process of FIG. 16A.
FIG. 18B is a flowchart of an operation execution process in step S1804 of FIG. 18A.
FIG. 19 is a flowchart illustrating a timer process.
FIG. 20 is a flowchart illustrating a server process according to the embodiment.
FIG. 21 is a diagram showing a description file format of a database.
FIG. 22 is a diagram illustrating a procedure for digesting an event.
FIG. 23 is a diagram for explaining an event synchronization procedure.

Claims (10)

In a system in which each of a plurality of processes holds and uses shared data shared by a plurality of processes communicable via an information transmission medium, information for maintaining the identity of the shared data held by each process Processing method,
A first issuing step of, when an operation request for the shared data is issued, issuing an operation event representing the operation request on the information transmission medium;
A second issuing step of issuing an issue prohibition event in response to a predetermined user operation;
An operation execution step of receiving a response operation event in response to the operation event issued by the first issuance step from outside, and executing an operation on the shared data;
And a prohibition step of prohibiting the issuance of the event by the first and second issuance steps after the issuance of the issuance prohibition event in the second issuance step and until an event corresponding to the issuance prohibition event is received. Information processing method. The second issuance step issues a digestion event as an operation prohibition event,
The method according to claim 1, wherein the prohibition step prohibits the issuance of the event by the first and second issuance steps from issuance of the digestion event to reception of an event responsive to the digestion event. Information processing method. The second issuing step issues a synchronization event as an operation prohibition event,
2. The information according to claim 1, wherein the prohibition step releases the prohibition of the issuance of the event based on a reception state of the synchronization event issued by the client itself and an event corresponding to the synchronization event issued by another client. Processing method. 4. The information processing method according to claim 3, wherein the prohibition step releases the event prohibition when the number of received synchronous events reaches a predetermined number. The information processing method according to claim 4, further comprising a setting step of setting the number of the synchronization events. The operation event has a time limit, and the operation execution step executes an operation corresponding to the operation event when the operation event has not been executed and the time limit has elapsed. The information processing method according to claim 1, wherein the prohibition state is released in response to the request. When an operation request occurs while the issuance of the operation event is prohibited by the prohibition step, a holding step of holding the operation request in a queue;
The first and second issuance steps include issuing an operation event or an operation inhibition event corresponding to the operation request held in the queue to the information transmission medium when the inhibition by the inhibition step is released. The information processing method according to claim 1, wherein: In a system in which each of a plurality of processes holds and uses shared data shared by a plurality of processes communicable via an information transmission medium, information for maintaining the identity of the shared data held by each process A processing device,
A first issuing unit that issues an operation event indicating the operation request on the information transmission medium when an operation request for the shared data occurs;
Second issuing means for issuing an issue prohibition event in response to a predetermined user operation;
Operation execution means for receiving, from the outside, a response operation event in response to the operation event issued by the first issuing means, and executing an operation on the shared data;
Prohibiting means for prohibiting issuance of an event by the first and second issuance means after issuance of an issuance prohibition event by the second issuance means until an event corresponding to the issuance prohibition event is received. Information processing device. A control program for causing a computer to execute the information processing method according to claim 1. A storage medium storing a control program for causing a computer to execute the information processing method according to claim 1.

Images