JPH10254755A - Permanent object system, sharing method for permanent object and updating method for permanent object data - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a permanent object system where plural pieces of software can share a permanent object. SOLUTION: In the permanent object system, plural pieces of software share the permanent object deciding an expression system on the file of plural pieces of software and reading/writing data between a memory and the file. A definition means defining a memory space loading the permanent object, a loading means (S34) loading the permanent object when a judgment means (S3) judges that the permanent object is not registered in the definition means and a registration means registering the memory space loaded on the permanent object by the loading means (S34) in the definition means are provided. Software and permanent object are associatively compiled (S36) so that the permanent object is loaded on the memory space defined by the definition means.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a persistent object system for determining a representation format of a plurality of software on a file and sharing the persistent object for reading and writing between a memory and a file by the plurality of software. , A method of sharing a persistent object, and a method of updating persistent object data.

[0002]

2. Description of the Related Art When software on a computer edits and browses a multimedia document, the document is usually stored as a file on a secondary storage device such as a disk. The software determines the expression format on the file separately from the expression format on the memory of the document, and reads and writes the document (conversion between the memory and the file) according to the user's instruction. At this time, by determining the representation format of the document on the files of the plurality of software and using a persistent object for reading and writing between the memory and the file of the document, the software:
As shown in FIG. 8, simply by determining the expression format of the document on the memory, the expression format of the document on the file in the secondary storage device is automatically determined, and the document can be stored in the file.

[0003] Documents to be browsed by a computer have conventionally been supported by specific software for editing and browsing. However, for example, HTML (Hyper Text Mark-up)
Language) Documents to be viewed, as typified by documents, are becoming independent from application programs for editing. Therefore, on a computer, it is necessary to interpret and reproduce the already popular document format or the standard document format for browsing. For mono-media data such as images, for example, reproduction for browsing a document does not have a variety of reproduction methods, but various reproduction methods are conceivable for multimedia documents such as HTML documents. That is, the user can browse the same document according to the preference and the purpose by different reproduction methods.

[0004] However, conventionally, when using data created by other software, it was necessary to interpret and convert the expression format determined by the other software. However, if a unified persistent object class library is used, data created by other software can be used without conversion. That is, an object generated from a class that handles still images can be used as an object that handles still images from any software.

FIG. 9 is an explanatory diagram for explaining the relationship between a document and a plurality of software. In FIG. 9, document a
And document b can be considered as a file on the secondary storage device. Here, when one document is used by a plurality of software at the same time, as shown in FIG. 9A, each software acquires a separate memory area, copies a document from a file, and Converting and using documents is not efficient. Therefore, as shown in FIG. 9B, if a permanent object is used, it is not necessary to convert a document. However, in this case as well, as shown in FIG. 10, each software needs to convert a persistent object into an internal object of each software, and when one software changes the object data, the They cannot be reflected, and the advantage of using persistent objects is halved.

Therefore, as shown in FIG. 1, it is conceivable to convert a persistent object 13 stored in a persistent object mechanism 12 into an internal object 14 of each software 15 and 16 so that the object can be shared. Thus, an object used by one software can be used by another software, and the storage of the object can be performed by the persistent object mechanism 12.
And the burden on software is reduced.

However, even in this case, there are the following problems. It is appropriate to provide the functionality of persistent objects as a class library. The operation mechanism of a general class library will be described below. For example, C ++
The language defines classes and methods. A class is a group of objects having the same function and property but different as individuals, and a method is a part describing a procedure.

When an object is created, a pointer to a method table is stored in the heap area, as shown in FIG. 11, in addition to the data of the object. The heap area is a common storage area used as needed during program execution. As shown in FIG. 11, the method table is located in a code area, and stores a pointer to a method (function) defined in the class. When a message is sent to the object, the program at the pointer of the method is started.

[0009]

Conventionally, there are two methods of linking a library, which is a collection of programs, statically and dynamically. In the method of statically linking, when compiling and linking a program, addresses of functions and methods included in a library are determined. In the dynamically linking method, the address of the method is determined at the time when the program is loaded. If the library is already in the memory, the used memory can be reduced by mapping the memory space to an appropriate own space.

In both the static and dynamic cases, as shown in FIG. 12, the area of the library to be linked is different for each process. Therefore, even if each software shares the persistent object in the shared memory, the address of the method table in the process space where each software first created the persistent object is described, and the address of the persistent object differs for each software, and one There is a problem that objects used by software cannot be used by other software.

Further, even when an object used by one piece of software can be used by another piece of software, when one piece of software updates the contents of object data, Attempting to do so also creates a conflict. In such a case, the lock and the semaphore are usually used to prevent other software from referencing / updating and then referencing / updating the object data. However, since persistent objects have characteristics that are frequently referenced, locking and excluding other software each time they are referenced does not take advantage of sharing persistent objects. Also, in order to avoid such a situation, a situation arises in which each software creates a copy.

The present invention has been made in view of the above circumstances, and it is an object of the first and second inventions to provide a persistent object system in which a plurality of software can share a persistent object. In the third invention,
An object of the present invention is to provide a persistent object system capable of updating persistent object data shared by software. The fourth and fifth inventions aim to provide a method of sharing a persistent object in which a plurality of software can share the persistent object. A sixth object of the present invention is to provide a method for updating persistent object data that can update persistent object data shared by software.

[0013]

According to a first aspect of the present invention, there is provided a persistent object system which determines a representation format of a plurality of software on a file, and reads and writes between a memory and a file between the plurality of software. A persistent object system for sharing, comprising: a defining unit that defines a memory space into which the persistent object is to be loaded; and a loading unit that loads the persistent object into the memory space defined by the defining unit. The software and the persistent object are cooperatively edited so that the persistent object is loaded into the memory space.

In this persistent object system, the defining means defines a memory space into which the persistent object is to be loaded, and the loading means loads the persistent object into the memory space defined by the defining means. Then, the software and the persistent object are cooperatively edited so that the persistent object is loaded into the memory space. This allows
In a link method in which a library that is a collection of programs is statically linked (coordinated editing), a plurality of software can share a persistent object.

According to a second aspect of the present invention, there is provided a persistent object system for determining a representation format of a plurality of software on a file, and for allowing the plurality of software to share a persistent object for reading and writing between a memory and a file. An object system, comprising: defining means for defining a memory space into which the persistent object is loaded; determining means for determining whether the persistent object is registered in the defining means; When it is determined that the persistent object is not registered, the loading means for loading the persistent object, and a registering means for registering the memory space loaded with the persistent object in the defining means, wherein the persistent object In the memory space defined by the definition means. As will be characterized by are none so as to link edited with the software and the persistent object.

In this persistent object system, the defining means defines a memory space into which the persistent object has been loaded, and the determining means determines whether or not the persistent object is registered in the defining means. Then, when the determining means determines that the persistent object is not registered,
The loading means loads the persistent object, the registering means registers the memory space loaded with the persistent object in the defining means, and the software and the persistent so that the persistent object is loaded in the memory space defined in the defining means. Link and edit objects. This allows a plurality of software to share a persistent object in a link method of dynamically linking (coordinating and editing) a library that is a collection of programs.

According to a third aspect of the present invention, there is provided a persistent object system for determining a representation format of a plurality of software on a file, and for allowing the plurality of software to share a persistent object for reading and writing between a memory and a file. An object system, comprising: distinguishing means for distinguishing persistent object data updated by the software from original persistent object data; and providing the plurality of software with any one of the original persistent object data and the updated persistent object data. Reference means for referring to the data, so that the software does not conflict with any of the plurality of software while updating the persistent object data.

In this persistent object system, the distinguishing means distinguishes the persistent object data updated by the software from the original persistent object data. Then, the reference means causes the plurality of software to refer to either the original persistent object data or the updated persistent object data so that the software does not conflict with any of the plurality of software while updating the persistent object data. I do. Thereby, the persistent object data shared by the software can be updated.

A method of sharing a persistent object according to a fourth aspect of the present invention is to determine a representation format of a plurality of software on a file, and to allow the plurality of software to share a persistent object for reading and writing between a memory and a file. Defining a memory space into which the persistent object is to be loaded, loading the persistent object into the defined memory space, and link-editing the software and the persistent object. .

In this method of sharing a persistent object, a memory space into which the persistent object is to be loaded is defined, the persistent object is loaded into the defined memory space, and software and the persistent object are linked and edited. This allows a plurality of software to share a persistent object in a link method of statically linking (coordinating and editing) a library that is a collection of programs.

According to a fifth aspect of the present invention, there is provided a method for sharing a persistent object in which a plurality of software share a persistent object for reading and writing between a memory and a file by determining an expression format on the file. A method of sharing a persistent object, wherein a memory space loaded with the persistent object is defined, it is determined whether the memory space is defined, and when it is determined that the memory space is not defined, Loading the persistent object, defining a memory space in which the persistent object was loaded, wherein the persistent object
The software and the persistent object are linked and edited so as to be loaded into a defined memory space.

In this method of sharing a persistent object, a memory space in which the persistent object is loaded is defined. Then, it is determined whether or not the memory space is defined. When it is determined that the memory space is not defined, the persistent object is loaded, the loaded memory space is defined, and the persistent object is defined. Co-edit software and persistent objects to be loaded into the allocated memory space. This allows a plurality of software to share a persistent object in a link method of dynamically linking (coordinating and editing) a library that is a collection of programs.

A method for updating a persistent object according to a sixth aspect of the present invention is a method of determining a representation format of a plurality of software on a file, wherein the plurality of software share a persistent object for reading and writing between a memory and a file, A method of updating persistent object data for the persistent object, the method comprising: distinguishing persistent object data updated by the software from original persistent object data; The method is characterized in that any one of the software and the updated persistent object data is referred to, and the software does not conflict with any of the plurality of software while updating the persistent object data.

In this method of updating a persistent object, the persistent object data updated by the software is distinguished from the original persistent object data. Then, a plurality of software is referred to either the original persistent object data or the updated persistent object data,
Ensure that software does not conflict with any of the multiple software while updating persistent object data. Thereby, the persistent object data shared by the software can be updated.

[0025]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described below with reference to the drawings showing an embodiment. FIG. 1 is a block diagram showing a configuration of an embodiment of a persistent object system, a method of sharing a persistent object, and a method of updating persistent object data according to the first to sixth aspects. The persistent object system converts the persistent object 13 stored in the persistent object mechanism 12 into, for example, software A
16 and the internal object 14 of the software B15. Documents a10 and b1 to be viewed
As for 1 and the like, the expression format on the file is determined by the internal object 14 shared by the software A16 and the software B15, and reading and writing between the memory and the file are performed.

FIG. 3 is a flowchart showing the operation of the persistent object system according to the first invention and the method for sharing a persistent object according to the fourth invention. Hereinafter, based on this flowchart, the operation of the persistent object system according to the first invention and the method of sharing the persistent object according to the fourth invention will be described. The persistent object system
After the software is compiled, an executable is created by the addressing linker. When there is a library (persistent object) to be linked (linked and edited) by the addressing type linker (S10), the
From the address table (defining means for defining the memory space into which the persistent object is to be loaded) (S
12). It is assumed that the address table shown in FIG. 2 can be referred to from all processes.

When the library to be linked is present in the address table (S12), the library is linked to the address described in the address table (S14) and the routine returns. On the other hand, when the library to be linked is not in the address table (S12), the address is determined by the conventional method (S18) and the process returns. When there is no library to be linked (S10), the addressing type linker saves the link result (S14, 18) in a file and ends the linking operation. The execution is the same as that of the conventional execution format loader.

FIG. 4 is a first flowchart showing the operation of the persistent object system according to the second invention and the method for sharing a persistent object according to the fifth invention. less than,
Based on this flowchart, the operation of the persistent object system according to the second invention and the method for sharing a persistent object according to the fifth invention will be described. The persistent object system loads an executable format compiled and linked by a conventional method using an addressable executable format loader. When there is a dynamic library (persistent object) to be loaded (S20), the addressing type executable format loader searches the library from the address table shown in FIG. 2 (S22).

When the library to be linked is in the address table (S22), the library is linked to the address described in the address table (S26), and the routine returns. On the other hand, if the library to be linked is not in the address table (S22), the shared library (permanent object) is loaded by instructing the addressing type shared library loader and registered in the address table (S24). (S26) and returns. When there is no dynamic library to be loaded (S20), the addressing type executable format loader shifts to other control (S28).

FIG. 5 is a second flowchart showing the operation of the persistent object system according to the second invention and the method for sharing a persistent object according to the fifth invention. less than,
Based on this flowchart, the operation of the persistent object system according to the second invention and the method for sharing a persistent object according to the fifth invention will be described. The persistent object system loads an executable format compiled and linked by a conventional method using an addressable executable format loader. When there is a dynamic library (permanent object) to be loaded (S30), the addressing type executable format loader searches the library from the address table shown in FIG. 2 by instructing the addressing type shared library loader (S30). S32).

An addressing type shared library loader
When the address table is searched and the library to be linked is present in the address table (S32), the addressing type executable format loader links the library to the address described in the address table (S36) and returns. On the other hand, the addressable shared library loader
When the library to be linked is not in the address table (S32), the shared library (persistent object) is loaded and registered in the address table (S34), and the addressing type executable format loader describes the shared library in the address table. Link to the address (S36)
To return. When there is no dynamic library to be loaded (S30), the addressing type executable format loader shifts to other control (S38).

FIG. 6 is an explanatory diagram for explaining a persistent object system according to the third invention and a method for updating persistent object data according to the sixth invention. In order to update the persistent object data without updating the persistent object data referenced by the software, a new persistent object may be created and the persistent object data may be updated. Further, in order to allow the updated persistent object data to be referred to from other software, a version is provided for each persistent object data to distinguish them.

There are two ways to realize the version. One of them is, as shown in FIG. 6A, a pointer pointing to a persistent object (object), and a pointer 21 for each version 1 to 3 of the persistent object data.
~ 23. The other is shown in FIG.
In this method, a plurality of versions 1 to 3 are provided in the persistent object 24 as shown in FIG. If the version is realized as described above, the software can refer to any version of the persistent object data by specifying the version.

FIG. 7 is an explanatory diagram for explaining a state in which software refers to a persistent object. In this case, a persistent object having one version is taken as an example. Software 1 and software 2 refer to this persistent object as shown in FIGS. 7A and 7B. When the software 1 updates the persistent object data, first, the version 2 persistent object data is created, and the software 1 refers to the version 2 persistent object data as shown in FIG. 7C. Since the software 2 does not yet know that the version 2 exists, the software 2 refers to the version 1 as shown in FIG.

Since the persistent object data updated by software 1 is created for version 2,
Version 1 referred to by software 2 is not affected. When the software 1 finishes updating as shown in FIG. 7 (e), as shown in FIG. 7 (f),
Version 2 can be referenced from all software. Software is version 1 and version 2
May or may not be referred to. As described above, only the updating software needs to lock the persistent object, and reference to the persistent object is not restricted. It is also possible to refer to the updated persistent object data.

[0036]

According to the persistent object system according to the first aspect of the present invention, a plurality of software can share a persistent object in a link system in which a library, which is a collection of programs, is statically linked (linked and edited).

According to the persistent object system according to the second aspect of the present invention, a plurality of software can share a persistent object in a link method of dynamically linking (coordinating and editing) a library as a collection of programs.

According to the persistent object system of the third aspect, the persistent object data shared by the software can be updated.

According to the method of sharing a persistent object according to the fourth aspect of the present invention, a plurality of software can share a persistent object in a link method of statically linking (coordinating and editing) a library which is a collection of programs.

According to the method of sharing a persistent object according to the fifth aspect of the present invention, a plurality of software can share a persistent object in a link method of dynamically linking (coordinating and editing) a library which is a collection of programs.

According to the method for updating persistent object data according to the sixth aspect, the persistent object data shared by the software can be updated.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration of an embodiment of a persistent object system, a method of sharing a persistent object, and a method of updating persistent object data according to the first to sixth inventions.

FIG. 2 is an explanatory diagram for explaining an address table.

FIG. 3 is a flowchart showing an operation of the persistent object system according to the first invention and a method of sharing a persistent object according to the fourth invention;

FIG. 4 is a first flowchart showing an operation of the persistent object system according to the second invention and a method of sharing a persistent object according to the fifth invention.

FIG. 5 is a second flowchart showing the operation of the persistent object system according to the second invention and the method for sharing the persistent object according to the fifth invention;

FIG. 6 is an explanatory diagram for explaining a persistent object system according to a third invention and a method of updating persistent object data according to the sixth invention.

FIG. 7 is an explanatory diagram for explaining a state in which software refers to a persistent object.

FIG. 8 is an explanatory diagram for explaining a persistent object.

FIG. 9 is an explanatory diagram for explaining a relationship between a document and a plurality of software.

FIG. 10 is an explanatory diagram for explaining a function of a conventional persistent object.

FIG. 11 is an explanatory diagram for describing a code area and a heap area.

FIG. 12 is an explanatory diagram for explaining an area of a library to be linked;

[Explanation of symbols]

 10 Document a 11 Document b 12 Permanent object mechanism 13 Persistent object 14 Internal object 15 Software (ware) B 16 Software (ware) A

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Kiyoshi Shibata 4-1-1, Kamiodanaka, Nakahara-ku, Kawasaki-shi, Kanagawa Prefecture Inside Fujitsu Limited (72) Inventor Toshihiro Sonoda 4-1-1, Kamiodanaka, Nakahara-ku, Kawasaki-shi, Kanagawa No. 1 Inside Fujitsu Limited

Claims (6)

[Claims] 1. A persistent object system for determining a representation format of a plurality of software on a file and sharing a persistent object for reading and writing between a memory and a file by the plurality of softwares. Defining means for defining a memory space into which an object is to be loaded, and loading means for loading the persistent object into the memory space defined by the defining means;
A persistent object system, wherein the software and the persistent object are cooperatively edited so that the persistent object is loaded into the memory space. 2. A persistent object system for determining a representation format of a plurality of software on a file and sharing a persistent object for reading and writing between a memory and a file by the plurality of softwares. Defining means for defining a memory space into which an object is loaded, determining means for determining whether the persistent object is registered in the defining means, and determining means that the persistent object is not registered A loading unit that loads the persistent object; and a registration unit that registers the memory space in which the loading unit has loaded the persistent object in the definition unit, wherein the persistent object is defined in the definition unit. The software and the Persistent object system, characterized in that you have no order to link edited the connection object. 3. A persistent object system for determining a representation format of a plurality of software on a file and sharing a persistent object for reading and writing between a memory and a file by the plurality of softwares. And distinguishing means for distinguishing the updated persistent object data from the original persistent object data, and referencing means for causing the plurality of software to refer to either the original persistent object data or the updated persistent object data. A persistent object system, wherein the software does not conflict with any of the plurality of software while updating the persistent object data. 4. A method of sharing a persistent object for determining a representation format of a plurality of software on a file and sharing a persistent object for reading and writing between a memory and a file by the plurality of software, A method for sharing a persistent object, comprising defining a memory space into which the persistent object is to be loaded, loading the persistent object into the defined memory space, and link-editing the software and the persistent object. 5. A method of sharing a persistent object for determining a representation format of a plurality of software on a file and sharing a persistent object for reading and writing between a memory and a file by the plurality of software, Defining a memory space into which the persistent object is loaded, determining whether or not the memory space is defined, and when determining that the memory space is not defined, loading the persistent object; A method of sharing a persistent object, comprising defining a memory space in which the software is loaded, and link-editing the software and the persistent object so that the persistent object is loaded into the defined memory space. 6. A method for determining a representation format of a plurality of software on a file, sharing a persistent object for reading and writing between a memory and a file by the plurality of software, and updating persistent object data for the persistent object. A method for updating persistent object data, comprising: distinguishing persistent object data updated by the software from original persistent object data; and providing the plurality of software with the original persistent object data and the updated persistent object data. A method of updating persistent object data, characterized by referring to any one of the plurality of pieces of software so that the software does not conflict with any of the plurality of pieces of software while updating the persistent object data.