CA2255131A1 - Method and apparatus for enforcing locking invariants in multi-threaded systems - Google Patents
Method and apparatus for enforcing locking invariants in multi-threaded systems Download PDFInfo
- Publication number
- CA2255131A1 CA2255131A1 CA002255131A CA2255131A CA2255131A1 CA 2255131 A1 CA2255131 A1 CA 2255131A1 CA 002255131 A CA002255131 A CA 002255131A CA 2255131 A CA2255131 A CA 2255131A CA 2255131 A1 CA2255131 A1 CA 2255131A1
- Authority
- CA
- Canada
- Prior art keywords
- lock
- code
- inverse
- upcall
- resource
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Abstract
In order to maintain locking invariants in a multi-threaded system, a special inverse lock class is defined whose constructor stores a reference to, and then releases, a previously-acquired lock whose reference is passed into it. Thedestructor of the class re-acquires the referenced lock. During operation, the class is instantiated, passing in the desired lock before an upcall is made.
Instantiation executes the constructor and causes the lock to be released. When the upcall terminates, either normally or by an exception, the inverse lock object destructor is executed causing the lock to be re-acquired. Since the inverse lock object destructor will always be called when the object is destroyed, the locking invariant will always be satisfied.
Instantiation executes the constructor and causes the lock to be released. When the upcall terminates, either normally or by an exception, the inverse lock object destructor is executed causing the lock to be re-acquired. Since the inverse lock object destructor will always be called when the object is destroyed, the locking invariant will always be satisfied.
Description
CA 022~131 1998-12-04 METHOD AND APPARATUS FOR ENFORCING LOCKING
INVARIANTS IN MULTI-THREADED SYSTEMS
FIELD OF THE INVENTION
This invention relates to distributed object systems using Common Object Request Broker Architecture (CORBA) and, more particularly, to a method and apparatus for implementing group object identification in object adapters.
BACKGROUND OF THE INVENTION
Software programs are continually becoming more complicated. Early programs consisted of straightforward procedural code that presented a simple, command line interface and text display to the user. These simple programs have gradually been replaced with complex programs that have graphical user interfaces and multiple features.
As programs have grown in complexity, the amount of effort which is required to write and debug the programs has also increased drastically.
Consequently, major efforts have been made to reduce the amount of programming necessary to produce a modern, full-featured product. One of the most successful of these efforts has been the development of object-oriented pro~ ml~ lg in which programs are designed as collections of discrete elements called "objects". The objects can be modified and re-used in many cases, therebyreducing the development effort.
As will be understood by those skilled in the art, objects in the context of object-oriented prog~ ""il-g are software entities comprising data and methods or operations on that data. The methods of an object collectively form an interface for manipulating the data in the object. The objects exist only at program runtime and are created, or instantiated, from object "classes" which are actually written by the programmer. The class code written by a programmer can be "reused" by another programmer by instantiating objects from that code.
.. ... . .. ... .... .
CA 022~131 1998-12-04 In order to further reduce the programming burden, distributed object systems have been developed in which methods in objects resident on a server can be executed or invoked remotely over a network from a client application.
In this manner, the objects can be developed and maintained by a party different5 from the party that developed the client application. In such a system information is routed or streamed between the client and the server. This information includes requests from the client to invoke an object on the server and results and data from the method invocation returning from the server to theclient. In addition, object-oriented programs often communicate by streaming 10 objects from one program to another.
In such streaming operations, a stream writer organizes, or marshals, the information to form a serial data stream. The serial data stream is then sent to the server where a stream reader unmarshals, the serial data stream to reconstruct acopy of the original information. The stream reader must operate such that the 15 unmarshaling exactly "undoes" the effect of the marshaling so that the original information can be reconstructed. Ordinarily, such an operation does not presenta problem, but when the stream reader is not written by the same author as the stream writer there can be incompatibilities.
In order to standardize the marshaling and unmarshaling and data transfer 20 process, an industry consortium called the Object Management Group (OMG) was formed whose mission is to define a set of interfaces for inter-operable software. Its first specification, the Common Object Request Broker Architecture (CORBA) specification, is an industry consensus standard that hidesall differences between programming languages, operating systems, and object 25 location. The CORBA standard defines an object request broker (ORB) that handles the marshaling, transport and unmarshaling of information between applications. The ORB functions as a communication infrastructure, transparently relaying object requests across distributed heterogeneous computing environments. Inter-operability is accomplished through well-defined 30 object interface specifications which allow client applications to connect to the CA 022~131 1998-12-04 ORB. CORBA provides an implementation independent notation for defining interfaces called the OMG Interface Definition Language (IDL).
The OMG CORBA specification defines an implementation independent object model which is actually built with a programming language, such as C++
5 or Java. In this model CORBA objects (also called "servants"), which are implemented by servers, have references that can be exported to clients. Clientsand servers are roles, not mutually exclusive tasks for a single program, so that any one program can be both a client and a server. Objects and object referencesare typically different pro~ g language objects, although they do not have 10 to be. An object may also be controlled by an object manager.
In a server, the implementation of an actual object which can be used to satisfy an invocation on a CORBA object is generally both platform and language dependent and various models are possible for implementing objects in servers. The original CORBA standard defined a Basic Object Adapter (or 15 BOA) which is a framework that adapts the server implementation to the implementation independent ORB. A newer OMG portability standard defines a Portable Object adapter (or POA), which replaces the BOA and is intended to be platform independent. Many ORBs also support other proprietary frameworks for implementing CORBA objects. All of these frameworks are commonly 20 referred to as Object Adapters (or OAs).
Invocations on servants are conventionally performed by invoking a method on an object reference. As part of this invocation, the manager for the particular object (if there is such a manager) is typically given control of theprocess at some point before, and typically after, the actual invocation on the 25 servant. There are many reasons for this transfer of control. For example, the object manager may have to create the servant, or the object manager may serialize all accesses to the servant. Alternatively, the servant's persistent data may need to be updated among other reasons.
When a multi-threaded ORB relinquishes control to the object manager, 30 it is important, and, in most cases mandatory, that the ORB release any resource ... . . .
CA 022~131 1998-12-04 locks it is holding while performing a particular invocation. The ORB may be holding such locks to ensure that accesses to data shared between multiple threads are controlled in order to avoid non-deterministic behavior. Examples of such shared data are tables, access to transports, repositories, etc.
It is important that the ORB release the locks when the object manager has control for a number of reasons. For example, the object manager may need to use functionality provided by the ORB, and, if the ORE~ does not release locks it is holding, a deadlock would occur where the object manager cannot use ORB
functionality, since the ORB itself is already locked. Another reason is that 10 while the object manager is active, another thread may wish to use the services provided by the ORB, and it can only do so if the locks that the ORB is holding have been released.
It is therefore important that, when the ORB relinquishes control during so-called "upcalls" - either to object managers, to servants, or to other entities, 15 it releases the locks it is holding while the upcall is taking place. However, it is also important that, as soon as the upcalls terminate - whether by normal termin~tion, or due to an exception, that the locks that were temporarily released are re-acquired. If the locks are not re-acquired, then the locking invariants for the ORB implementation are broken, potentially causing deadlocks which will 20 stop the process from executing.
Therefore, it would be desirable to have a simple mechanism for enforcing the locking invariants during upcalls.
SUMMARY OF THE INVENTION
In accordance with the principles of the invention, a special inverse lock class is defined whose constructor stores a reference to, and then releases, a previously-acquired lock whose reference is passed into it. The destructor of the class re-acquires the referenced lock. During operation, the class is instantiated, passing in the desired lock before an upcall is made. Instantiation executes the30 constructor and causes the lock to be released. When the upcall termin~tes, CA 022~131 1998-12-04 either normally or by an exception, the inverse lock object destructor is executed causing the lock to be re-acquired. Since the inverse lock object destructor will always be called when the object is destroyed, the locking invariant will alwaysbe satisfied.
BRIEF DESCRIPTION OF THE DRAWINGS
The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings in which:
Figure l is a schematic block diagram of an illustrative prior art hardware platform which forms part of a computer system on which the invention can be run.
Figure 2 is a schematic diagram of a prior art computer network system on which a CORBA system can be built.
Figure 3 is a block schematic diagram illustrating a prior art CORBA
environment and showing the relationship of the client, ORB, object adapter and server.
Figure 4A illustrates a multi-threaded ORB holding a lock to a resource.
Figure 4B illustrates the multi-threaded ORB releasing the resource lock and transferring control to user code during an upcall.
Figure 4C illustrates the user code returning control to the multi-threaded ORB at the termination of the upcall and the ORB re-acquiring the resource lock.Figure 5 is a simplified class diagram illustrating the relationship of a lockholder object and an InverseLockHolder object to a lock object.
Figure 6 is a flowchart showing an illustrative upcall procedure using the InverseLockHolder object to release and re-acquire the lock during an upcall procedure.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
CA 022~131 1998-12-04 Figure 1 illustrates the system architecture for an exemplary client computer 100, such as an IBM THINKPAD 701~ computer or Digital Equipment Corporation HiNote computer, on which the disclosed network access system (system) can be implemented. The exemplary computer system of Figure 1 is discussed only for descriptive purposes, however, and should not be considered a limitation of the invention. Although the description below may refer to terms commonly used in describing particular computer systems, the described concepts apply equally to other computer systems, including systems having architectures that are dissimilar to that shown in Figure 1.
The client computer 100 includes a central processing unit (CPU) 105, which may include a conventional microprocessor, random access memory (RAM) 110 for temporary storage of information, and read only memory (ROM) 115 for permanent storage of information. A memory controller 120 is provided for controlling system RAM 110. A bus controller 125 is provided for controlling bus 130, and an interrupt controller 135 is used for receiving and processing various interrupt signals from the other system components.
Mass storage may be provided by diskette 142, CD-ROM 147, or hard disk 152. Data and software may be exchanged with client computer 100 via removable media, such as diskette 142 and CD-ROM 147. Diskette 142 is insertable into diskette drive 141, which is connected to bus 130 by controller 140. Similarly, CD-ROM 147 is insertable into CD-ROM drive 146, which is connected to bus 130 by controller 145. Finally, the hard disk 152 is part of a fixed disk drive 151, which is connected to bus 130 by controller 150.
User input to the client computer 100 may be provided by a number of devices. For example, a keyboard 156 and a mouse 157 may be connected to bus 130 by keyboard and mouse controller 155. An audio transducer 196, which may act as both a microphone and a speaker, is connected to bus 130 by audio controller 197. It should be obvious to those reasonably skilled in the art thatother input devices, such as a pen and/or tablet and a microphone for voice input, may be connected to client computer 100 through bus 130 and an a~propl;ate ._. .. . .... .
CA 022~131 1998-12-04 controller. DMA controller 160 is provided for performing direct memory access to system RAM 110. A visual display is generated by a video controller 165, which controls video display 170.
Client computer 100 also includes a network adapter 190 that allows the client computer 100 to be interconnected to a network 195 via a bus 191. The network 195, which may be a local area network (LAN), a wide area network (WAN), or the Internet, may utilize general purpose communication lines that interconnect multiple network devices.
Client computer system 100 generally is controlled and coordinated by 10 operating system software, such as the WINDOWS 95~ operating system (available from Microsoft Corp., Redmond, WA). Among other computer system control functions, the operating system controls allocation of system resources and performs tasks such as process scheduling, memory management, networking and I/O services.
Figure 2 illustrates, in a very simple fashion, the connection of a number of computing systems, such as that shown in Figure 1, to form a distributed computing facility. Each ofthe individual stations 200, 202, 204, 208 and 210 are interconnected by a network mechanism. Although the distributing computing facility could exist on a single computing system, it is more likely to operate over a network transport medium. Such a transport medium may be LAN as shown in Figure 2, but may also be other network arrangements, including the Internet. All that is necessary is that the terminals 200, 202, 204, 208 and 210 be able to communicate with each other using predefined protocols to exchange information. As previously mentioned, the CORBA architecture overlays such a network and relieves the individual applications from dealing with the details of transporting information over the network. More particularly, the CORBA architecture hides all of the details and the actual network protocolsfrom the application programs. It assures that the application programs operate with each other regardless of the platforms on which the software is designed to ~ ._ _ .. . . .
CA 022~131 1998-12-04 run and regardless of the network protocols used to interconnect separate computing systems.
Figure 3 illustrates, in a very schematic form, the basic CORBA
architecture which defines a peer-to-peer distributed computing facility where all 5 applications are objects (in the sense of object orientation). Objects can alternate between client roles 300 and server roles 302. An object operates in a client role 300 when it is the originator of an object invocation. An object operates in a server role 302, called an object implementation, when it is the recipient of anobject invocation.
The client 300 communicates with the server 302 by means of an object request broker or ORB 308. The ORB 308 operates with a transport 310 that conveys information between the client 300 and server 302 and, as previously mentioned, the ORB 308 handles the marshaling, transport and unmarshaling of information between client 300 and server 302. The client 300 communicates with the ORB 308, as indicated schematically by arrow 304, by means of an implementation independent syntax which describes object encapsulations. This syntax is called an interface definition language (IDL) and is defined in the CORBA specification generated by OMG. The OMG interface definition language can be used to define interfaces that have attributes and operation signatures. The language also supports inheritance between interface descriptions in order to facilitate reuse by developers. Objects or servants in the server 302 export object references with interfaces specified by the OMG IDL
for use by clients. The object reference contains an identification of the object implementation so that the server 302 can pass a request to the correct object.
The entire CORBA architecture is actually implemented in a conventional programming language, such as C, C++, or Smalltalk. Implementations in a variety of languages are available from a number of vendors who typically provide a compiler bundled with their ORB products. The compilers generate header files which define the OMG IDL interfaces and can be incorporated into CA 022~131 1998-12-04 application programs. The compilers also generate stub code 306 and skeleton code 314 for each interface.
The client application program 300 can directly link directly to the OMG
IDL stub code 306. As far as the client application program is concerned, an invocation of the stub code 306 appears to be a local function call. Once invoked, the stub code 306 provides an interface to the ORB 308 that performs marshaling to encode and decode the operation's parameters into communication formats suitable for transmission on the transport 310 to the server 302.
At the server side, the OMG IDL skeleton code 314 is the corresponding 10 implementation of the OMG IDL interface. When the ORB 308 receives a request, the skeleton code 314 unmarshals the request parameters and generates a call~ indicated schematically by arrow 312, to an object implementation in theserver 302. When the server completes processing of the request, the skeleton code 314 and stub code 306 return the results to the client program 300. If an 15 error has occurred, exception information generated by the server or by the ORB
is returned.
An object adapter 316 comprises the interface between the ORB 308, the skeleton code 314 and the server 302. Object adapters, such as adapter 316, support functions, such as registration of object implementations and activation20 of servers.
Figures 4A, 4B and 4C illustrate a multi-threaded ORB performing an upcall to client-written code. During this operation a lock on a resource is released and then re-acquired. Figure 4 shows two ORB threads 400 and 410.
ORB thread 400 is holding the lock 404 which controls a resource 406. The 25 acquisition of lock 404 by ORB thread 400 is indicated in line 402 and would be accomplished in a conventional manner. In the illustrative sequence, ORB thread 400 will perform an upcall to user code 408.
As shown in Figure 4B, ORB thread 400 releases the lock 404 and performs the upcall to user code 408, for example, by means of a method call as 30 schematically illustrated by arrow 412. In accordance with the invention the g CA 022~131 1998-12-04 method call 412 instantiates an "inverse lock" object 416 as schematically illustrated by arrow 420. The inverse lock object 416 stores a reference to lock404 in an internal variable 418. The inverse lock object releases the lock as indicated by dotted arrow 402. At this time, another ORB thread, for example, ORB thread 410, is free to acquire lock 404 as indicated by line 414.
Finally, as shown in Figure 4C, user code 408 returns control to ORB
thread 400 as indicated by arrow 422. ORB thread 400 then must re-acquire lock 404 in order to maintain the locking invariants. Either explicitly, or implicitly, the return 422 causes the inverse lock object 416 to be destroyed as indicated by 10 the dotted object 416. The destruction of object 416 re-acquires the lock 404 as indicated by arrow 402. Multi-thread safe operations can then be performed by threads 400 and 410.
Figure 5 illustrates the relation of a conventional lock holder object and the inventive "inverse lock holder" object to the acquire() and release() methods 15 in a lock object. The lock holder object 500 includes a constructor 506 whichexecutes a hold() method. The hold() method, in turn, invokes the acquire() method 510 of the lock object 502, passing in a reference to the lock. Thus, when the lock holder object 500 is instantiated, the lock encapsulated in the lock object 502 is acquired and the passed in lock reference is stored in an internal20 variable S09. Conversely, when the lock holder object 500 is destroyed, its destructor, 508, executes a release() method that invokes the release() method 512 of the lock object 502, thereby releasing the lock.
In accordance with the principles of the invention, the inverse lock holder object 504 operates in an opposite manner. The constructor 514 ofthe inverse 25 lock holder object 504 invokes the release() method 510 of the lock object 502.
Thus, when the inverse lock holder object 504 is instantiated, a lock whose reference is passed into the constructor is released. As will be hereinafter explained, when the inverse lock holder object 504 is instantiated, the passed in lock reference is stored in an internal variable 518. When the inverse lock holder CA 022~131 1998-12-04 object 504 is destroyed, its destructor 516 locates the referenced lock object 502 and invokes the acquire() method 510 to re-acquire the lock.
It is important that the prog~ g language which is used to implement the inverse lock holder object force the execution of the destructor whether the5 inverse lock holder object is destroyed during normal operation or whether theinverse lock holder object is destroyed during an abnormal termin~tion, such as an exception. For example, the C++ proglallllning language allows the definitionof classes, which can have user-defined constructors and destructors. The destructor is invoked whenever an instance of a class is destroyed, regardless of 10 normal or abnormal termination. The C++ programming language specification guarantees this - no matter how execution is proceeding. In the following description the C++ programming language is used to illustrate the invention, although it can be expressed in other programming languages as well subject to the requirement that the object destructor must always be run when the object is1 5 destroyed.
Assuming that a class implementing a multi-threaded lock (called Lock) has been defined, with two methods called "release" and "acquire" for releasing and acquiring the lock, respectively, an InverseLockHolder class could be implemented in the C++ language as follows:
class InverseLockHolder {
Lock &the_lock;
public:
InverseLockHolder(Lock &lock): the_lock(lock) {
the_lock.release(); ll the inverse lock object constructor Il releases the lock }
CA 022~131 1998-12-04 ~InverseLockHolder() { ll the inverse lock object destructor the_lock.acquire(); ll re-acquires the lock };
In alternative implementation, "acquire()" and "release()" methods can be included in the InverseLockHolder class for additional control. Such an illustrative implementation could be as follows:
class InverseLockHolder {
int held;
Lock &the_lock;
public:
InverseLockHolder(Lock &lock): the_lock(lock) {
release(); ll the inverse lock object //constructor releases the lock }
void release() { held = 0; the_lock.release(); }
void acquire() { the_lock.acquire(); held= l; }
~InverseLockHolder() {
if (!held) acquire(); ll the inverse lock object //destructor acquires the 30 lock if CA 022~131 1998-12-04 //not already held }
};
Although instances of the InverseLockHolder can be allocated dynamically, they are typically allocated "on the stack" by defining them. The C++ language guarantees that objects allocated "on the stack" will be destroyed regardless of normal or abnormal termination.
The operation of the InverseLockHolder object during an upcall made by an ORB is illustrated in Figure 6. The operation starts at step 600 and proceedsto step 602 where a lock is acquired by conventional means, such as by instantiating a lock holder object 500. Next, in step 604, the ORB invokes a method which performs the upcall. This method instantiates an InverseLockHolder object and passes in a reference to the lock. As previously mentioned, operation of the constructor in the InverseLockHolder object 504, causes the operation set forth in step 606 in which the InverseLockHolder storesthe lock ID and then releases the lock. Next, in step 608, the upcall method performs the upcall operation.
In step 610, the return from the upcall method destroys the InverseLockHolder. The InverseLockHolder may be destroyed explicitly by a call to its destructor in the upcall method, or in those systems which employ memory management techniques such as garbage collection, the object will be destroyed by the operating system. In either case, the InverseLockHolder destructor is invoked and re-acquires the lock. Finally, in step 612, the end of the operation destroys the lock holder object, which, in turn, releases the lock and the routine finishes in step 614.
An illustrative C++ coding of such an operation is shown in the following code fragment:
void do_operation_with_upcall() {
Lock lock;
CA 022~131 1998-12-04 LockHolder hold(lock);
//INVA~ANT: the lock is now held ... multi-thread safe operations can happen here //COMMENT: prepare for an upcall InverseLockHolder do_not_hold(lock) //INVA~ANT: the lock is now NOT held Il other threads can have access to shared resources 1 5 do_the_upcall();
}
Il INVARIANT: the lock is now held again ... multi-thread safe operations can happen here return; ll when the function returns, Il the LockHolder object will release the lock }
Therefore, with the help of the LockHolder and the InverseLockHolder, the locking invariants can be guaranteed. This reduces potential programming errors and prevents deadlocks of the programs using the objects.
A software implementation of the above-described embodiment may 30 comprise a series of computer instructions either fixed on a tangible medium, CA 022~131 1998-12-04 such as a computer readable media, e.g. diskette 142, CD-ROM 147, ROM 115, or fixed disk 152 of Figure 1, or transmittable to a computer system, via a modem or other interface device, such as communications adapter 190 connected to the network 195 over a medium 191. Medium 191 can be either a tangible 5 medium, including but not limited to optical or analog communications lines, or may be implemented with wireless techniques, including but not limited to microwave, infrared or other transmission techniques. It may also be the Internet. The series of computer instructions embodies all or part of the functionality previously described herein with respect to the invention. Those 10 skilled in the art will appreciate that such computer instructions can be written in a number of progl~-"~ g languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including, but not limited to, semiconductor, magnetic, optical or other memory devices, or transmitted using 15 any communications technology, present or future, including but not limited to optical, infrared, microwave, or other transmission technologies. It is contemplated that such a computer program product may be distributed as a removable media with accompanying printed or electronic documentation, e.g., shrink wrapped software, pre-loaded with a computer system, e.g., on system 20 ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, e.g., the Internet or World Wide Web.
Although an exemplary embodiment of the invention has been disclosed, it will be apparent to those skilled in the art that various changes and modifications can be made which will achieve some of the advantages of the 25 invention without departing from the spirit and scope of the invention. For example, it will be obvious to those reasonably skilled in the art that, although the problem stated above was described in terms of multi-threaded ORB
implementations, it applies to other multi-threaded programs as well. For example, such multi-threaded programs may need to relinquish control to at least30 partially user-written code. When control is released the programs will typically CA 022~131 1998-12-04 need to release locks, at least while the upcall is taking place. Further, as stated above the inventive object can be implemented in a programming language other than C++. Other aspects such as the specific configuration of logic and/or instructions utilized to achieve a particular function, as well as other 5 modifications to the inventive concept are intended to be covered by the appended claims.
l~
. . _ . . . . .
INVARIANTS IN MULTI-THREADED SYSTEMS
FIELD OF THE INVENTION
This invention relates to distributed object systems using Common Object Request Broker Architecture (CORBA) and, more particularly, to a method and apparatus for implementing group object identification in object adapters.
BACKGROUND OF THE INVENTION
Software programs are continually becoming more complicated. Early programs consisted of straightforward procedural code that presented a simple, command line interface and text display to the user. These simple programs have gradually been replaced with complex programs that have graphical user interfaces and multiple features.
As programs have grown in complexity, the amount of effort which is required to write and debug the programs has also increased drastically.
Consequently, major efforts have been made to reduce the amount of programming necessary to produce a modern, full-featured product. One of the most successful of these efforts has been the development of object-oriented pro~ ml~ lg in which programs are designed as collections of discrete elements called "objects". The objects can be modified and re-used in many cases, therebyreducing the development effort.
As will be understood by those skilled in the art, objects in the context of object-oriented prog~ ""il-g are software entities comprising data and methods or operations on that data. The methods of an object collectively form an interface for manipulating the data in the object. The objects exist only at program runtime and are created, or instantiated, from object "classes" which are actually written by the programmer. The class code written by a programmer can be "reused" by another programmer by instantiating objects from that code.
.. ... . .. ... .... .
CA 022~131 1998-12-04 In order to further reduce the programming burden, distributed object systems have been developed in which methods in objects resident on a server can be executed or invoked remotely over a network from a client application.
In this manner, the objects can be developed and maintained by a party different5 from the party that developed the client application. In such a system information is routed or streamed between the client and the server. This information includes requests from the client to invoke an object on the server and results and data from the method invocation returning from the server to theclient. In addition, object-oriented programs often communicate by streaming 10 objects from one program to another.
In such streaming operations, a stream writer organizes, or marshals, the information to form a serial data stream. The serial data stream is then sent to the server where a stream reader unmarshals, the serial data stream to reconstruct acopy of the original information. The stream reader must operate such that the 15 unmarshaling exactly "undoes" the effect of the marshaling so that the original information can be reconstructed. Ordinarily, such an operation does not presenta problem, but when the stream reader is not written by the same author as the stream writer there can be incompatibilities.
In order to standardize the marshaling and unmarshaling and data transfer 20 process, an industry consortium called the Object Management Group (OMG) was formed whose mission is to define a set of interfaces for inter-operable software. Its first specification, the Common Object Request Broker Architecture (CORBA) specification, is an industry consensus standard that hidesall differences between programming languages, operating systems, and object 25 location. The CORBA standard defines an object request broker (ORB) that handles the marshaling, transport and unmarshaling of information between applications. The ORB functions as a communication infrastructure, transparently relaying object requests across distributed heterogeneous computing environments. Inter-operability is accomplished through well-defined 30 object interface specifications which allow client applications to connect to the CA 022~131 1998-12-04 ORB. CORBA provides an implementation independent notation for defining interfaces called the OMG Interface Definition Language (IDL).
The OMG CORBA specification defines an implementation independent object model which is actually built with a programming language, such as C++
5 or Java. In this model CORBA objects (also called "servants"), which are implemented by servers, have references that can be exported to clients. Clientsand servers are roles, not mutually exclusive tasks for a single program, so that any one program can be both a client and a server. Objects and object referencesare typically different pro~ g language objects, although they do not have 10 to be. An object may also be controlled by an object manager.
In a server, the implementation of an actual object which can be used to satisfy an invocation on a CORBA object is generally both platform and language dependent and various models are possible for implementing objects in servers. The original CORBA standard defined a Basic Object Adapter (or 15 BOA) which is a framework that adapts the server implementation to the implementation independent ORB. A newer OMG portability standard defines a Portable Object adapter (or POA), which replaces the BOA and is intended to be platform independent. Many ORBs also support other proprietary frameworks for implementing CORBA objects. All of these frameworks are commonly 20 referred to as Object Adapters (or OAs).
Invocations on servants are conventionally performed by invoking a method on an object reference. As part of this invocation, the manager for the particular object (if there is such a manager) is typically given control of theprocess at some point before, and typically after, the actual invocation on the 25 servant. There are many reasons for this transfer of control. For example, the object manager may have to create the servant, or the object manager may serialize all accesses to the servant. Alternatively, the servant's persistent data may need to be updated among other reasons.
When a multi-threaded ORB relinquishes control to the object manager, 30 it is important, and, in most cases mandatory, that the ORB release any resource ... . . .
CA 022~131 1998-12-04 locks it is holding while performing a particular invocation. The ORB may be holding such locks to ensure that accesses to data shared between multiple threads are controlled in order to avoid non-deterministic behavior. Examples of such shared data are tables, access to transports, repositories, etc.
It is important that the ORB release the locks when the object manager has control for a number of reasons. For example, the object manager may need to use functionality provided by the ORB, and, if the ORE~ does not release locks it is holding, a deadlock would occur where the object manager cannot use ORB
functionality, since the ORB itself is already locked. Another reason is that 10 while the object manager is active, another thread may wish to use the services provided by the ORB, and it can only do so if the locks that the ORB is holding have been released.
It is therefore important that, when the ORB relinquishes control during so-called "upcalls" - either to object managers, to servants, or to other entities, 15 it releases the locks it is holding while the upcall is taking place. However, it is also important that, as soon as the upcalls terminate - whether by normal termin~tion, or due to an exception, that the locks that were temporarily released are re-acquired. If the locks are not re-acquired, then the locking invariants for the ORB implementation are broken, potentially causing deadlocks which will 20 stop the process from executing.
Therefore, it would be desirable to have a simple mechanism for enforcing the locking invariants during upcalls.
SUMMARY OF THE INVENTION
In accordance with the principles of the invention, a special inverse lock class is defined whose constructor stores a reference to, and then releases, a previously-acquired lock whose reference is passed into it. The destructor of the class re-acquires the referenced lock. During operation, the class is instantiated, passing in the desired lock before an upcall is made. Instantiation executes the30 constructor and causes the lock to be released. When the upcall termin~tes, CA 022~131 1998-12-04 either normally or by an exception, the inverse lock object destructor is executed causing the lock to be re-acquired. Since the inverse lock object destructor will always be called when the object is destroyed, the locking invariant will alwaysbe satisfied.
BRIEF DESCRIPTION OF THE DRAWINGS
The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings in which:
Figure l is a schematic block diagram of an illustrative prior art hardware platform which forms part of a computer system on which the invention can be run.
Figure 2 is a schematic diagram of a prior art computer network system on which a CORBA system can be built.
Figure 3 is a block schematic diagram illustrating a prior art CORBA
environment and showing the relationship of the client, ORB, object adapter and server.
Figure 4A illustrates a multi-threaded ORB holding a lock to a resource.
Figure 4B illustrates the multi-threaded ORB releasing the resource lock and transferring control to user code during an upcall.
Figure 4C illustrates the user code returning control to the multi-threaded ORB at the termination of the upcall and the ORB re-acquiring the resource lock.Figure 5 is a simplified class diagram illustrating the relationship of a lockholder object and an InverseLockHolder object to a lock object.
Figure 6 is a flowchart showing an illustrative upcall procedure using the InverseLockHolder object to release and re-acquire the lock during an upcall procedure.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
CA 022~131 1998-12-04 Figure 1 illustrates the system architecture for an exemplary client computer 100, such as an IBM THINKPAD 701~ computer or Digital Equipment Corporation HiNote computer, on which the disclosed network access system (system) can be implemented. The exemplary computer system of Figure 1 is discussed only for descriptive purposes, however, and should not be considered a limitation of the invention. Although the description below may refer to terms commonly used in describing particular computer systems, the described concepts apply equally to other computer systems, including systems having architectures that are dissimilar to that shown in Figure 1.
The client computer 100 includes a central processing unit (CPU) 105, which may include a conventional microprocessor, random access memory (RAM) 110 for temporary storage of information, and read only memory (ROM) 115 for permanent storage of information. A memory controller 120 is provided for controlling system RAM 110. A bus controller 125 is provided for controlling bus 130, and an interrupt controller 135 is used for receiving and processing various interrupt signals from the other system components.
Mass storage may be provided by diskette 142, CD-ROM 147, or hard disk 152. Data and software may be exchanged with client computer 100 via removable media, such as diskette 142 and CD-ROM 147. Diskette 142 is insertable into diskette drive 141, which is connected to bus 130 by controller 140. Similarly, CD-ROM 147 is insertable into CD-ROM drive 146, which is connected to bus 130 by controller 145. Finally, the hard disk 152 is part of a fixed disk drive 151, which is connected to bus 130 by controller 150.
User input to the client computer 100 may be provided by a number of devices. For example, a keyboard 156 and a mouse 157 may be connected to bus 130 by keyboard and mouse controller 155. An audio transducer 196, which may act as both a microphone and a speaker, is connected to bus 130 by audio controller 197. It should be obvious to those reasonably skilled in the art thatother input devices, such as a pen and/or tablet and a microphone for voice input, may be connected to client computer 100 through bus 130 and an a~propl;ate ._. .. . .... .
CA 022~131 1998-12-04 controller. DMA controller 160 is provided for performing direct memory access to system RAM 110. A visual display is generated by a video controller 165, which controls video display 170.
Client computer 100 also includes a network adapter 190 that allows the client computer 100 to be interconnected to a network 195 via a bus 191. The network 195, which may be a local area network (LAN), a wide area network (WAN), or the Internet, may utilize general purpose communication lines that interconnect multiple network devices.
Client computer system 100 generally is controlled and coordinated by 10 operating system software, such as the WINDOWS 95~ operating system (available from Microsoft Corp., Redmond, WA). Among other computer system control functions, the operating system controls allocation of system resources and performs tasks such as process scheduling, memory management, networking and I/O services.
Figure 2 illustrates, in a very simple fashion, the connection of a number of computing systems, such as that shown in Figure 1, to form a distributed computing facility. Each ofthe individual stations 200, 202, 204, 208 and 210 are interconnected by a network mechanism. Although the distributing computing facility could exist on a single computing system, it is more likely to operate over a network transport medium. Such a transport medium may be LAN as shown in Figure 2, but may also be other network arrangements, including the Internet. All that is necessary is that the terminals 200, 202, 204, 208 and 210 be able to communicate with each other using predefined protocols to exchange information. As previously mentioned, the CORBA architecture overlays such a network and relieves the individual applications from dealing with the details of transporting information over the network. More particularly, the CORBA architecture hides all of the details and the actual network protocolsfrom the application programs. It assures that the application programs operate with each other regardless of the platforms on which the software is designed to ~ ._ _ .. . . .
CA 022~131 1998-12-04 run and regardless of the network protocols used to interconnect separate computing systems.
Figure 3 illustrates, in a very schematic form, the basic CORBA
architecture which defines a peer-to-peer distributed computing facility where all 5 applications are objects (in the sense of object orientation). Objects can alternate between client roles 300 and server roles 302. An object operates in a client role 300 when it is the originator of an object invocation. An object operates in a server role 302, called an object implementation, when it is the recipient of anobject invocation.
The client 300 communicates with the server 302 by means of an object request broker or ORB 308. The ORB 308 operates with a transport 310 that conveys information between the client 300 and server 302 and, as previously mentioned, the ORB 308 handles the marshaling, transport and unmarshaling of information between client 300 and server 302. The client 300 communicates with the ORB 308, as indicated schematically by arrow 304, by means of an implementation independent syntax which describes object encapsulations. This syntax is called an interface definition language (IDL) and is defined in the CORBA specification generated by OMG. The OMG interface definition language can be used to define interfaces that have attributes and operation signatures. The language also supports inheritance between interface descriptions in order to facilitate reuse by developers. Objects or servants in the server 302 export object references with interfaces specified by the OMG IDL
for use by clients. The object reference contains an identification of the object implementation so that the server 302 can pass a request to the correct object.
The entire CORBA architecture is actually implemented in a conventional programming language, such as C, C++, or Smalltalk. Implementations in a variety of languages are available from a number of vendors who typically provide a compiler bundled with their ORB products. The compilers generate header files which define the OMG IDL interfaces and can be incorporated into CA 022~131 1998-12-04 application programs. The compilers also generate stub code 306 and skeleton code 314 for each interface.
The client application program 300 can directly link directly to the OMG
IDL stub code 306. As far as the client application program is concerned, an invocation of the stub code 306 appears to be a local function call. Once invoked, the stub code 306 provides an interface to the ORB 308 that performs marshaling to encode and decode the operation's parameters into communication formats suitable for transmission on the transport 310 to the server 302.
At the server side, the OMG IDL skeleton code 314 is the corresponding 10 implementation of the OMG IDL interface. When the ORB 308 receives a request, the skeleton code 314 unmarshals the request parameters and generates a call~ indicated schematically by arrow 312, to an object implementation in theserver 302. When the server completes processing of the request, the skeleton code 314 and stub code 306 return the results to the client program 300. If an 15 error has occurred, exception information generated by the server or by the ORB
is returned.
An object adapter 316 comprises the interface between the ORB 308, the skeleton code 314 and the server 302. Object adapters, such as adapter 316, support functions, such as registration of object implementations and activation20 of servers.
Figures 4A, 4B and 4C illustrate a multi-threaded ORB performing an upcall to client-written code. During this operation a lock on a resource is released and then re-acquired. Figure 4 shows two ORB threads 400 and 410.
ORB thread 400 is holding the lock 404 which controls a resource 406. The 25 acquisition of lock 404 by ORB thread 400 is indicated in line 402 and would be accomplished in a conventional manner. In the illustrative sequence, ORB thread 400 will perform an upcall to user code 408.
As shown in Figure 4B, ORB thread 400 releases the lock 404 and performs the upcall to user code 408, for example, by means of a method call as 30 schematically illustrated by arrow 412. In accordance with the invention the g CA 022~131 1998-12-04 method call 412 instantiates an "inverse lock" object 416 as schematically illustrated by arrow 420. The inverse lock object 416 stores a reference to lock404 in an internal variable 418. The inverse lock object releases the lock as indicated by dotted arrow 402. At this time, another ORB thread, for example, ORB thread 410, is free to acquire lock 404 as indicated by line 414.
Finally, as shown in Figure 4C, user code 408 returns control to ORB
thread 400 as indicated by arrow 422. ORB thread 400 then must re-acquire lock 404 in order to maintain the locking invariants. Either explicitly, or implicitly, the return 422 causes the inverse lock object 416 to be destroyed as indicated by 10 the dotted object 416. The destruction of object 416 re-acquires the lock 404 as indicated by arrow 402. Multi-thread safe operations can then be performed by threads 400 and 410.
Figure 5 illustrates the relation of a conventional lock holder object and the inventive "inverse lock holder" object to the acquire() and release() methods 15 in a lock object. The lock holder object 500 includes a constructor 506 whichexecutes a hold() method. The hold() method, in turn, invokes the acquire() method 510 of the lock object 502, passing in a reference to the lock. Thus, when the lock holder object 500 is instantiated, the lock encapsulated in the lock object 502 is acquired and the passed in lock reference is stored in an internal20 variable S09. Conversely, when the lock holder object 500 is destroyed, its destructor, 508, executes a release() method that invokes the release() method 512 of the lock object 502, thereby releasing the lock.
In accordance with the principles of the invention, the inverse lock holder object 504 operates in an opposite manner. The constructor 514 ofthe inverse 25 lock holder object 504 invokes the release() method 510 of the lock object 502.
Thus, when the inverse lock holder object 504 is instantiated, a lock whose reference is passed into the constructor is released. As will be hereinafter explained, when the inverse lock holder object 504 is instantiated, the passed in lock reference is stored in an internal variable 518. When the inverse lock holder CA 022~131 1998-12-04 object 504 is destroyed, its destructor 516 locates the referenced lock object 502 and invokes the acquire() method 510 to re-acquire the lock.
It is important that the prog~ g language which is used to implement the inverse lock holder object force the execution of the destructor whether the5 inverse lock holder object is destroyed during normal operation or whether theinverse lock holder object is destroyed during an abnormal termin~tion, such as an exception. For example, the C++ proglallllning language allows the definitionof classes, which can have user-defined constructors and destructors. The destructor is invoked whenever an instance of a class is destroyed, regardless of 10 normal or abnormal termination. The C++ programming language specification guarantees this - no matter how execution is proceeding. In the following description the C++ programming language is used to illustrate the invention, although it can be expressed in other programming languages as well subject to the requirement that the object destructor must always be run when the object is1 5 destroyed.
Assuming that a class implementing a multi-threaded lock (called Lock) has been defined, with two methods called "release" and "acquire" for releasing and acquiring the lock, respectively, an InverseLockHolder class could be implemented in the C++ language as follows:
class InverseLockHolder {
Lock &the_lock;
public:
InverseLockHolder(Lock &lock): the_lock(lock) {
the_lock.release(); ll the inverse lock object constructor Il releases the lock }
CA 022~131 1998-12-04 ~InverseLockHolder() { ll the inverse lock object destructor the_lock.acquire(); ll re-acquires the lock };
In alternative implementation, "acquire()" and "release()" methods can be included in the InverseLockHolder class for additional control. Such an illustrative implementation could be as follows:
class InverseLockHolder {
int held;
Lock &the_lock;
public:
InverseLockHolder(Lock &lock): the_lock(lock) {
release(); ll the inverse lock object //constructor releases the lock }
void release() { held = 0; the_lock.release(); }
void acquire() { the_lock.acquire(); held= l; }
~InverseLockHolder() {
if (!held) acquire(); ll the inverse lock object //destructor acquires the 30 lock if CA 022~131 1998-12-04 //not already held }
};
Although instances of the InverseLockHolder can be allocated dynamically, they are typically allocated "on the stack" by defining them. The C++ language guarantees that objects allocated "on the stack" will be destroyed regardless of normal or abnormal termination.
The operation of the InverseLockHolder object during an upcall made by an ORB is illustrated in Figure 6. The operation starts at step 600 and proceedsto step 602 where a lock is acquired by conventional means, such as by instantiating a lock holder object 500. Next, in step 604, the ORB invokes a method which performs the upcall. This method instantiates an InverseLockHolder object and passes in a reference to the lock. As previously mentioned, operation of the constructor in the InverseLockHolder object 504, causes the operation set forth in step 606 in which the InverseLockHolder storesthe lock ID and then releases the lock. Next, in step 608, the upcall method performs the upcall operation.
In step 610, the return from the upcall method destroys the InverseLockHolder. The InverseLockHolder may be destroyed explicitly by a call to its destructor in the upcall method, or in those systems which employ memory management techniques such as garbage collection, the object will be destroyed by the operating system. In either case, the InverseLockHolder destructor is invoked and re-acquires the lock. Finally, in step 612, the end of the operation destroys the lock holder object, which, in turn, releases the lock and the routine finishes in step 614.
An illustrative C++ coding of such an operation is shown in the following code fragment:
void do_operation_with_upcall() {
Lock lock;
CA 022~131 1998-12-04 LockHolder hold(lock);
//INVA~ANT: the lock is now held ... multi-thread safe operations can happen here //COMMENT: prepare for an upcall InverseLockHolder do_not_hold(lock) //INVA~ANT: the lock is now NOT held Il other threads can have access to shared resources 1 5 do_the_upcall();
}
Il INVARIANT: the lock is now held again ... multi-thread safe operations can happen here return; ll when the function returns, Il the LockHolder object will release the lock }
Therefore, with the help of the LockHolder and the InverseLockHolder, the locking invariants can be guaranteed. This reduces potential programming errors and prevents deadlocks of the programs using the objects.
A software implementation of the above-described embodiment may 30 comprise a series of computer instructions either fixed on a tangible medium, CA 022~131 1998-12-04 such as a computer readable media, e.g. diskette 142, CD-ROM 147, ROM 115, or fixed disk 152 of Figure 1, or transmittable to a computer system, via a modem or other interface device, such as communications adapter 190 connected to the network 195 over a medium 191. Medium 191 can be either a tangible 5 medium, including but not limited to optical or analog communications lines, or may be implemented with wireless techniques, including but not limited to microwave, infrared or other transmission techniques. It may also be the Internet. The series of computer instructions embodies all or part of the functionality previously described herein with respect to the invention. Those 10 skilled in the art will appreciate that such computer instructions can be written in a number of progl~-"~ g languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including, but not limited to, semiconductor, magnetic, optical or other memory devices, or transmitted using 15 any communications technology, present or future, including but not limited to optical, infrared, microwave, or other transmission technologies. It is contemplated that such a computer program product may be distributed as a removable media with accompanying printed or electronic documentation, e.g., shrink wrapped software, pre-loaded with a computer system, e.g., on system 20 ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, e.g., the Internet or World Wide Web.
Although an exemplary embodiment of the invention has been disclosed, it will be apparent to those skilled in the art that various changes and modifications can be made which will achieve some of the advantages of the 25 invention without departing from the spirit and scope of the invention. For example, it will be obvious to those reasonably skilled in the art that, although the problem stated above was described in terms of multi-threaded ORB
implementations, it applies to other multi-threaded programs as well. For example, such multi-threaded programs may need to relinquish control to at least30 partially user-written code. When control is released the programs will typically CA 022~131 1998-12-04 need to release locks, at least while the upcall is taking place. Further, as stated above the inventive object can be implemented in a programming language other than C++. Other aspects such as the specific configuration of logic and/or instructions utilized to achieve a particular function, as well as other 5 modifications to the inventive concept are intended to be covered by the appended claims.
l~
. . _ . . . . .
Claims (39)
1. Apparatus for enforcing locking invariants in a multi-threaded system with a memory in which a first program holding a resource lock performs an upcall operation to a second program, the apparatus comprising:
inverse lock holder class code in the memory having constructor method code which constructs an inverse lock holder object and releases the resource lock, and destructor method code which acquires the resource lock and destroys the inverse lock holder object;
an upcall method in the first program which instantiates the inverse lock holder class code and then performs the upcall operation; and a mechanism in the multi-threaded system which destroys an instantiated inverse lock holder object when the upcall method finishes.
inverse lock holder class code in the memory having constructor method code which constructs an inverse lock holder object and releases the resource lock, and destructor method code which acquires the resource lock and destroys the inverse lock holder object;
an upcall method in the first program which instantiates the inverse lock holder class code and then performs the upcall operation; and a mechanism in the multi-threaded system which destroys an instantiated inverse lock holder object when the upcall method finishes.
2. Apparatus according to claim 1 wherein the resource lock has a reference and wherein the upcall method passes the reference to the constructor method code during the instantiation.
3. Apparatus according to claim 2 wherein the inverse lock holder object comprises an internal variable for holding the reference to the resource lock, which reference is stored by the constructor method code.
4. Apparatus according to claim 3 wherein the destructor method code, prior to destruction of the inverse lock holder object, re-acquires a resource lock identified by the reference stored in the internal variable.
5. Apparatus according to claim 1 wherein the resource lock is contained within a lock object having an acquire method for acquiring the resource lock and a release method for releasing the resource lock.
6. Apparatus according to claim 5 wherein the lock object constructor method calls the acquire method of the lock object.
7. Apparatus according to claim 5 wherein the lock object destructor method calls the release method of the lock object.
8. Apparatus according to claim 1 wherein the mechanism comprises a method for explicitly calling the inverse lock holder object destructor method code.
9. Apparatus according to claim 1 wherein the multi-threaded system comprises an operating system and wherein the mechanism comprises a method in the operating system for destroying unused objects.
10. A method for enforcing locking invariants in a multi-threaded system with a memory in which a first program holding a resource lock performs an upcall operation to a second program, the method comprising the steps of:
(a) creating inverse lock holder class code in the memory having constructor method code which constructs an inverse lock holder object and releases the resource lock, and destructor method code which acquires the resource lock and destroys the inverse lock holder object;
(b) invoking an upcall method in the first program which instantiates the inverse lock holder class code and then performs the upcall operation; and (c) destroying an instantiated inverse lock holder object when the upcall method finishes.
(a) creating inverse lock holder class code in the memory having constructor method code which constructs an inverse lock holder object and releases the resource lock, and destructor method code which acquires the resource lock and destroys the inverse lock holder object;
(b) invoking an upcall method in the first program which instantiates the inverse lock holder class code and then performs the upcall operation; and (c) destroying an instantiated inverse lock holder object when the upcall method finishes.
11. A method according to claim 10 wherein the resource lock has a reference and wherein step (b) comprises the step of:
(b1) passing the reference to the constructor method code during the instantiation.
(b1) passing the reference to the constructor method code during the instantiation.
12. A method according to claim 11 wherein the inverse lock holder object comprises an internal variable and step (b) comprises the step of:
(b2) storing the reference to the resource lock in the internal variable.
(b2) storing the reference to the resource lock in the internal variable.
13. A method according to claim 12 wherein in step (c) the destructor method code re-acquires a resource lock identified by the reference stored in the internal variable.
14. A method according to claim 10 further comprising the step of:
(d) instantiating a lock object containing the resource lock and having an acquire method for acquiring the resource lock and a release method for releasing the resource lock.
(d) instantiating a lock object containing the resource lock and having an acquire method for acquiring the resource lock and a release method for releasing the resource lock.
15. A method according to claim 14 wherein in step (b) the constructor method code calls the lock object acquire method.
16. A method according to claim 14 wherein in step (c) the destructor method code calls the lock object release method.
17. A method according to claim 10 wherein step (c) comprises the step of:
(c1) explicitly calling the inverse lock holder object destructor method code.
(c1) explicitly calling the inverse lock holder object destructor method code.
18. A method according to claim 10 wherein the multi-threaded system comprises an operating system and wherein step (c) comprises the step of:
(c2) invoking a method in the operating system for destroying unused objects.
(c2) invoking a method in the operating system for destroying unused objects.
19. A computer program product for enforcing locking invariants in a multi-threaded system with a memory in which a first program holding a resource lock performs an upcall operation to a second program, the computer program product comprising a computer usable medium having computer readable program code thereon including:
inverse lock holder class code having constructor method code which constructs an inverse lock holder object and releases the resource lock, and destructor method code which acquires the resource lock and destroys the inverse lock holder object;
upcall method code in the first program which instantiates the inverse lock holder class code and then performs the upcall operation; and program code which destroys an instantiated inverse lock holder object when the upcall method finishes.
inverse lock holder class code having constructor method code which constructs an inverse lock holder object and releases the resource lock, and destructor method code which acquires the resource lock and destroys the inverse lock holder object;
upcall method code in the first program which instantiates the inverse lock holder class code and then performs the upcall operation; and program code which destroys an instantiated inverse lock holder object when the upcall method finishes.
20. A computer program product according to claim 19 wherein the resource lock has a reference and wherein the upcall method code comprises program code for passing the reference to the constructor method code during the instantiation.
21. A computer program product according to claim 20 wherein the inverse lock holder object comprises an internal variable and wherein the constructor method code comprises program code for storing the reference to the resource lock in the internal variable.
22. A computer program product according to claim 21 wherein the destructor method code includes program code for re-acquiring a resource lock identified by the reference stored in the internal variable.
23. A computer program product according to claim 19 further comprising constructor code for instantiating a lock object containing the resource lock, which lock object has an acquire method for acquiring the resource lock and a release method for releasing the resource lock.
24. A computer program product according to claim 23 wherein the inverse lock holder constructor method code includes program code for calling the lock object acquire method.
25. A computer program product according to claim 23 wherein the inverse lock holder destructor method code includes program code for calling the lock object release method.
26. A computer program product according to claim 19 wherein the program code for destroying the inverse lock holder object when the upcall method finishes comprises program code for explicitly calling the inverse lock holder object destructor method code.
27. A computer program product according to claim 19 wherein the program code for destroying the inverse lock holder object comprises a method in the operating system for destroying unused objects.
28. Apparatus for enforcing locking invariants in a CORBA distributed object system with a memory in which an object request broker instantiates a lock object to acquire a resource lock, the apparatus comprising:
inverse lock holder class code in the memory having constructor method code which constructs an inverse lock holder object, stores a reference to the resource lock in the memory and then causes the lock object to release the resource lock, and destructor method code which causes the lock object to re-acquire the resource lock and then destroys the inverse lock holder object;
an upcall method in the object request broker which instantiates the inverse lock holder class code to construct an inverse lock holder object and then performs an upcall operation to a server program; and a mechanism in the distributed object system which destroys all objects instantiated by the upcall method when the upcall method returns.
inverse lock holder class code in the memory having constructor method code which constructs an inverse lock holder object, stores a reference to the resource lock in the memory and then causes the lock object to release the resource lock, and destructor method code which causes the lock object to re-acquire the resource lock and then destroys the inverse lock holder object;
an upcall method in the object request broker which instantiates the inverse lock holder class code to construct an inverse lock holder object and then performs an upcall operation to a server program; and a mechanism in the distributed object system which destroys all objects instantiated by the upcall method when the upcall method returns.
29. Apparatus according to claim 28 wherein the server program comprises a mechanism for acquiring the resource lock during the upcall operation.
30. Apparatus according to claim 28 wherein the object request broker is multi-threaded and a first thread of the multi-threaded object request broker instantiates the lock object to acquire the resource lock and then invokes the upcall method.
31. Apparatus according to claim 30 wherein a second thread of the multi-threaded object request broker acquires the resource lock during the upcall operation.
32. Apparatus according to claim 30 wherein the lock object is destroyed by the distributed object system when the first thread terminates.
33. Apparatus according to claim 30 wherein the lock object is destroyed by the first thread invoking the lock object destructor.
34. A method for enforcing locking invariants in a CORBA distributed object system with a memory in which an object request broker instantiates a lock object to acquire a resource lock, the method comprising the steps of:
(a) creating inverse lock holder class code in the memory having constructor method code which constructs an inverse lock holder object, stores a reference to the resource lock in the memory and then causes the lock object to release the resource lock, and destructor method code which causes the lock object to re-acquire the resource lock and then destroys the inverse lock holder object;
(b) invoking an upcall method in the object request broker which instantiates the inverse lock holder class code to construct an inverse lock holder object and then performs an upcall operation to a server program; and (c) destroying all objects instantiated by the upcall method when the upcall method returns.
(a) creating inverse lock holder class code in the memory having constructor method code which constructs an inverse lock holder object, stores a reference to the resource lock in the memory and then causes the lock object to release the resource lock, and destructor method code which causes the lock object to re-acquire the resource lock and then destroys the inverse lock holder object;
(b) invoking an upcall method in the object request broker which instantiates the inverse lock holder class code to construct an inverse lock holder object and then performs an upcall operation to a server program; and (c) destroying all objects instantiated by the upcall method when the upcall method returns.
35. A method according to claim 34 further comprising the step of:
(d) using the server program to acquire the resource lock during the upcall operation.
(d) using the server program to acquire the resource lock during the upcall operation.
36. A method according to claim 34 wherein the object request broker is multi-threaded and step (b) comprises the steps of:
(b1) using a first thread of the multi-threaded object request broker to instantiate the lock object and acquire the resource lock; and (b2) using the first thread to invoke the upcall method.
(b1) using a first thread of the multi-threaded object request broker to instantiate the lock object and acquire the resource lock; and (b2) using the first thread to invoke the upcall method.
37. A method according to claim 36 further comprising the step of:
(e) using a second thread of the multi-threaded object request broker to acquire the resource lock during the upcall operation.
(e) using a second thread of the multi-threaded object request broker to acquire the resource lock during the upcall operation.
38. A method according to claim 36 further comprising the step of:
(f) using the distributed object system to destroy the lock object when the first thread terminates.
(f) using the distributed object system to destroy the lock object when the first thread terminates.
39. A method according to claim 36 further comprising the step of:
(g) invoking the lock object destructor with the first thread.
(g) invoking the lock object destructor with the first thread.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/993,206 | 1997-12-18 | ||
| US08/993,206 US6510460B1 (en) | 1997-12-18 | 1997-12-18 | Method and apparatus for enforcing locking invariants in multi-threaded systems |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2255131A1 true CA2255131A1 (en) | 1999-06-18 |
Family
ID=25539235
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002255131A Abandoned CA2255131A1 (en) | 1997-12-18 | 1998-12-04 | Method and apparatus for enforcing locking invariants in multi-threaded systems |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6510460B1 (en) |
| EP (1) | EP0924616A2 (en) |
| JP (1) | JP2000003288A (en) |
| CA (1) | CA2255131A1 (en) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6836887B1 (en) * | 1998-12-21 | 2004-12-28 | Microsoft Corporation | Recyclable locking for multi-threaded computing environments |
| US6836888B1 (en) * | 2000-03-17 | 2004-12-28 | Lucent Technologies Inc. | System for reverse sandboxing |
| US7487152B1 (en) * | 2000-05-31 | 2009-02-03 | International Business Machines Corporation | Method for efficiently locking resources of a global data repository |
| US7571439B1 (en) * | 2002-05-31 | 2009-08-04 | Teradata Us, Inc. | Synchronizing access to global resources |
| US7117498B2 (en) * | 2002-06-14 | 2006-10-03 | Intel Corporation | Thread optimization for lock and unlock operations in a multi-thread environment |
| US20070112771A1 (en) * | 2005-11-04 | 2007-05-17 | Sun Microsystems, Inc. | Directory entry locks |
| US9229959B2 (en) | 2013-01-04 | 2016-01-05 | Microsoft Technology Licensing, Llc | Object graph partial immutability and isolation enforcement |
| US9098269B2 (en) | 2013-01-04 | 2015-08-04 | Microsoft Technology Licensing, Llc | System and method to ensure resource access safety with immutable object types |
Family Cites Families (67)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4823310A (en) | 1987-08-10 | 1989-04-18 | Wang Laboratories, Inc. | Device for enabling concurrent access of indexed sequential data files |
| US5012409A (en) * | 1988-03-10 | 1991-04-30 | Fletcher Mitchell S | Operating system for a multi-tasking operating environment |
| US5218699A (en) | 1989-08-24 | 1993-06-08 | International Business Machines Corporation | Remote procedure calls in heterogeneous systems |
| AU639802B2 (en) | 1990-08-14 | 1993-08-05 | Oracle International Corporation | Methods and apparatus for providing dynamic invocation of applications in a distributed heterogeneous environment |
| US5263160A (en) | 1991-01-31 | 1993-11-16 | Digital Equipment Corporation | Augmented doubly-linked list search and management method for a system having data stored in a list of data elements in memory |
| CA2098461A1 (en) | 1992-06-17 | 1993-12-18 | Antony S. Williams | Method and system for registering data formats for objects |
| JPH06103075A (en) | 1992-07-06 | 1994-04-15 | Internatl Business Mach Corp <Ibm> | Operation for object-oriented application |
| US5307490A (en) | 1992-08-28 | 1994-04-26 | Tandem Computers, Inc. | Method and system for implementing remote procedure calls in a distributed computer system |
| US5329619A (en) | 1992-10-30 | 1994-07-12 | Software Ag | Cooperative processing interface and communication broker for heterogeneous computing environments |
| US5566302A (en) | 1992-12-21 | 1996-10-15 | Sun Microsystems, Inc. | Method for executing operation call from client application using shared memory region and establishing shared memory region when the shared memory region does not exist |
| DE69327448T2 (en) | 1992-12-21 | 2004-03-04 | Sun Microsystems, Inc., Mountain View | Method and device for subtasks in a distributed processing system |
| US5379432A (en) * | 1993-07-19 | 1995-01-03 | Taligent, Inc. | Object-oriented interface for a procedural operating system |
| US5455951A (en) * | 1993-07-19 | 1995-10-03 | Taligent, Inc. | Method and apparatus for running an object-oriented program on a host computer with a procedural operating system |
| US5581680A (en) | 1993-10-06 | 1996-12-03 | Silicon Graphics, Inc. | Method and apparatus for antialiasing raster scanned images |
| US5481706A (en) * | 1993-11-01 | 1996-01-02 | International Business Machines Corporation | System and method for creating thread-safe shared libraries |
| US5515508A (en) | 1993-12-17 | 1996-05-07 | Taligent, Inc. | Client server system and method of operation including a dynamically configurable protocol stack |
| US5491800A (en) | 1993-12-20 | 1996-02-13 | Taligent, Inc. | Object-oriented remote procedure call networking system |
| US5465363A (en) * | 1993-12-30 | 1995-11-07 | Orton; Debra L. | Wrapper system for enabling a non-multitasking application to access shared resources in a multitasking environment |
| US5734903A (en) | 1994-05-13 | 1998-03-31 | Apple Computer, Inc. | System and method for object oriented message filtering |
| US5540014A (en) | 1994-06-15 | 1996-07-30 | Smith; A. Graeme | Plant cover |
| US5832487A (en) | 1994-12-15 | 1998-11-03 | Novell, Inc. | Replicated object identification in a partitioned hierarchy |
| US5758342A (en) | 1995-01-23 | 1998-05-26 | International Business Machines Corporation | Client server based multi-processor file system wherein client files written to by a client processor are invisible to the server |
| US5790848A (en) | 1995-02-03 | 1998-08-04 | Dex Information Systems, Inc. | Method and apparatus for data access and update in a shared file environment |
| EP0729097A1 (en) * | 1995-02-07 | 1996-08-28 | Sun Microsystems, Inc. | Method and apparatus for run-time memory access checking and memory leak detection of a multi-threaded program |
| US5819093A (en) | 1995-03-03 | 1998-10-06 | Sun Microsystems, Inc. | System and method for a distributed debugger for debugging distributed application programs |
| US5793965A (en) * | 1995-03-22 | 1998-08-11 | Sun Microsystems, Inc. | Method and apparatus for determining the type of an object in a distributed object system |
| US5907675A (en) * | 1995-03-22 | 1999-05-25 | Sun Microsystems, Inc. | Methods and apparatus for managing deactivation and shutdown of a server |
| US5724503A (en) | 1995-03-31 | 1998-03-03 | Sun Microsystems, Inc. | Method and apparatus for interpreting exceptions in a distributed object system |
| US5787447A (en) | 1995-05-08 | 1998-07-28 | Sun Microsystems, Inc. | Memory allocation maintaining ordering across multiple heaps |
| US5748963A (en) | 1995-05-12 | 1998-05-05 | Design Intelligence, Inc. | Adaptive binding |
| US5852731A (en) * | 1995-06-05 | 1998-12-22 | International Business Machines Corporation | Computer program product for synchronizing static variable initialization and reference under a multi-threaded computer environment |
| US5761499A (en) * | 1995-12-21 | 1998-06-02 | Novell, Inc. | Method for managing globally distributed software components |
| US5881315A (en) | 1995-08-18 | 1999-03-09 | International Business Machines Corporation | Queue management for distributed computing environment to deliver events to interested consumers even when events are generated faster than consumers can receive |
| US5682534A (en) | 1995-09-12 | 1997-10-28 | International Business Machines Corporation | Transparent local RPC optimization |
| US5892946A (en) | 1995-09-12 | 1999-04-06 | Alcatel Usa, Inc. | System and method for multi-site distributed object management environment |
| US5737607A (en) * | 1995-09-28 | 1998-04-07 | Sun Microsystems, Inc. | Method and apparatus for allowing generic stubs to marshal and unmarshal data in object reference specific data formats |
| JP3426428B2 (en) | 1995-10-27 | 2003-07-14 | 富士通株式会社 | Transaction tracing device |
| JP3097525B2 (en) | 1995-11-10 | 2000-10-10 | 株式会社日立製作所 | Data transmission method for performing information filtering |
| US5958006A (en) | 1995-11-13 | 1999-09-28 | Motorola, Inc. | Method and apparatus for communicating summarized data |
| US5761670A (en) * | 1995-12-08 | 1998-06-02 | Sun Microsystems, Inc. | System and method for space efficient object locking using global and local locks |
| US5751962A (en) | 1995-12-13 | 1998-05-12 | Ncr Corporation | Object-based systems management of computer networks |
| US5870753A (en) | 1996-03-20 | 1999-02-09 | International Business Machines Corporation | Method and apparatus for enabling a persistent metastate for objects in an object oriented environment |
| US5848236A (en) | 1996-03-22 | 1998-12-08 | Sun Microsystems, Inc. | Object-oriented development framework for distributed hardware simulation |
| US5928323A (en) * | 1996-05-30 | 1999-07-27 | Sun Microsystems, Inc. | Apparatus and method for dynamically generating information with server-side software objects |
| US5862376A (en) * | 1996-06-24 | 1999-01-19 | Sun Microsystems, Inc. | System and method for space and time efficient object locking |
| US5727145A (en) | 1996-06-26 | 1998-03-10 | Sun Microsystems, Inc. | Mechanism for locating objects in a secure fashion |
| US6044409A (en) * | 1996-06-26 | 2000-03-28 | Sun Microsystems, Inc. | Framework for marshaling and unmarshaling argument object references |
| US5991823A (en) | 1996-06-26 | 1999-11-23 | Sun Microsystems, Inc. | Low overhead object adaptor |
| US5974410A (en) | 1996-06-28 | 1999-10-26 | Microsoft Corporation | Method and system for filtering in a uniform data interface |
| US5815703A (en) | 1996-06-28 | 1998-09-29 | Microsoft Corporation | Computer-based uniform data interface (UDI) method and system using an application programming interface (API) |
| US5835906A (en) | 1996-07-01 | 1998-11-10 | Sun Microsystems, Inc. | Methods and apparatus for sharing stored data objects in a computer system |
| US5809507A (en) | 1996-07-01 | 1998-09-15 | Sun Microsystems, Inc. | Method and apparatus for storing persistent objects on a distributed object network using a marshaling framework |
| US5915252A (en) | 1996-09-30 | 1999-06-22 | International Business Machines Corporation | Object oriented framework mechanism for data transfer between a data source and a data target |
| US6128640A (en) * | 1996-10-03 | 2000-10-03 | Sun Microsystems, Inc. | Method and apparatus for user-level support for multiple event synchronization |
| US5873116A (en) | 1996-11-22 | 1999-02-16 | International Business Machines Corp. | Method and apparatus for controlling access to data structures without the use of locks |
| US5913038A (en) | 1996-12-13 | 1999-06-15 | Microsoft Corporation | System and method for processing multimedia data streams using filter graphs |
| US5870805A (en) | 1997-01-06 | 1999-02-16 | Baxter International Inc. | Disposable tubing set and organizer frame for holding flexible tubing |
| US5864866A (en) | 1997-03-26 | 1999-01-26 | International Business Machines Corporation | Apparatus and method for providing externalization in an object-oriented environment |
| GB2326492B (en) * | 1997-06-20 | 2002-03-20 | Ibm | Apparatus, method and computer program for providing arbitrary locking modes for controlling concurrent access to server resources |
| JPH1139209A (en) * | 1997-07-07 | 1999-02-12 | Internatl Business Mach Corp <Ibm> | Device and method for controlling access to computer resource |
| GB2327134B (en) * | 1997-07-08 | 2002-04-03 | Ibm | Apparatus,method and computer program for providing arbitrary locking requesters for controlling concurrent access to server resources |
| US6016499A (en) | 1997-07-21 | 2000-01-18 | Novell, Inc. | System and method for accessing a directory services respository |
| US5978940A (en) | 1997-08-20 | 1999-11-02 | Mci Communications Corporation | System method and article of manufacture for test operations |
| US5926775A (en) * | 1997-10-08 | 1999-07-20 | National Instruments Corporation | Mini driver software architecture for a data acquisition system |
| US6026401A (en) * | 1997-10-14 | 2000-02-15 | International Business Machines Corporation | Locking tool data objects in a framework environment |
| US6185609B1 (en) * | 1997-10-24 | 2001-02-06 | Sun Microsystems, Inc. | Method, apparatus and program to provide client access to a management information service residing on a server in a computer network system |
| US5946680A (en) | 1997-11-28 | 1999-08-31 | International Business Machines Corporation | Method of determining the unique ID of an object in a peer to peer configuration of object indexes |
-
1997
- 1997-12-18 US US08/993,206 patent/US6510460B1/en not_active Expired - Lifetime
-
1998
- 1998-12-04 CA CA002255131A patent/CA2255131A1/en not_active Abandoned
- 1998-12-11 JP JP10377826A patent/JP2000003288A/en not_active Withdrawn
- 1998-12-16 EP EP98123891A patent/EP0924616A2/en not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| US6510460B1 (en) | 2003-01-21 |
| EP0924616A2 (en) | 1999-06-23 |
| JP2000003288A (en) | 2000-01-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6405264B1 (en) | Marshaling and unmarshaling framework for supporting filters in a distributed object system | |
| Schmidt et al. | Applying patterns to develop extensible ORB middleware | |
| US6976261B2 (en) | Method and apparatus for fast, local CORBA object references | |
| Schmidt | Applying patterns and frameworks to develop object-oriented communication software | |
| US6507875B1 (en) | Modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources | |
| US6249803B1 (en) | Method and apparatus for executing code during method invocation | |
| US7020880B2 (en) | Modular application collaborator for providing inter-operability between applications and monitoring errors to trigger execution of required compensating actions to undo interrupted transaction | |
| EP1025493B1 (en) | Queued method invocations on distributed component applications | |
| US6434543B1 (en) | System and method for reliable caching of database connections in a distributed application | |
| US7424549B2 (en) | System, method, and article of manufacture for using a replaceable component to select a replaceable quality of service capable network communication channel component | |
| EP0924613A2 (en) | Method and apparatus for constructing stable iterators in a shared data collection | |
| US6516354B2 (en) | Method and apparatus for efficient representation of variable length identifiers in a distributed object system | |
| US6205491B1 (en) | Method and apparatus for deferred throwing of exceptions in C++ | |
| Maybee et al. | Multilanguage interoperability in distributed systems. Experience report | |
| US6510460B1 (en) | Method and apparatus for enforcing locking invariants in multi-threaded systems | |
| Warren et al. | A model for dynamic configuration which preserves application integrity | |
| Simons et al. | FastCGI the forgotten treasure | |
| Moons et al. | Object invocation in the COMET open distributed system: the dialogue model | |
| Harrison et al. | Asynchronous Completion Token | |
| Design, implementation and performance evaluation of a CORBA atomic broadcast protocol | ||
| Schmidt | An Object Behavioral Pattern for Concurrent Event Demultiplexing and Dispatching | |
| Zhang | A comparative study of DCOM/CORBA and. NET/J2EE | |
| Hasegawa | Research into the interoperability of enterprise information technologies |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |