Resource allocation

Distributed resource management system using hashing operation to direct resource request from different processors to the processor controlling the requested resource

5301337

Abstract

A resource managing method operates in a computer system in which a variety of processes run essentially simultaneously on a group of processors, each processor being provided with a respective section of memory which is also accessible by the other processors in the group though typically not as quickly as by the respective processor. Resource data objects corresponding to particular resources are located by means of a hash table which is divided into portions which are distributed over respective sections of the overall system memory. A resource manager program, which is essentially replicated for each processor, implements a hashing algorithm which directs requests for access to designated resources to the corresponding portion of the hash table irrespective of which processor originated the request. Each section of the hash table includes a series of entries which provide pointers to respective lists of resource data objects which hash to that entry. The resource data objects, as well as various other data objects, are distributed over the different memory sections and include data elements which implement basic protection latches using a read-modify-write instruction.


Claims

What is claimed is:

1. A computer implemented method for cooperatively managing resources which may be needed by a variety of processes running simultaneously on a group of processors each of which is provided with a respective section of memory which is also accessible by other processors in the group, a resource manager program which is replicated for each said processor in its respective section of memory and which is responsive to calls from processes seeking access to resources or release of resources, and a hash table which is divided into portions, each said portion comprised of a series of entries, which are distributed over respective sections of said memory, said method comprising the computer implemented steps of:

implementing a hashing algorithm by said resource manager program which directs calls form processes seeking access to a designated resource to a unique memory address location for a unique one of said memory sections associated with the designated resource irrespective of which processors originated the calls, said memory address location storing a hash table entry corresponding to the designated resource,

associating, in the unique one of said memory sections, with a corresponding portion of the hash table a plurality of resource data objects,

assigning to the designated resource one of the plurality of resource data objects which records information regarding the processes which have access or are seeking access to the designated resource,

placing said one of the plurality of resource data objects in a list of resource data objects which are assigned to resources which hash to said entry corresponding to the designated resource,

providing said entry corresponding to the designated resource with a pointer which points to said list of resource data objects, and,

accessing, through said one of the plurality of resource data objects, said designated resource by said processes seeking access.

2. A method as set forth in claim 1 further comprising a multiplicity of lock data objects which can be acquired by a process for requesting access to resource data object and which can record information regarding the state of access to the respective resource by that process.

3. A method as set forth in claim 2 wherein said manager program operates to adjust the lock data objects of other processes requesting a given resource when releasing access to said given resource thereby to reflect the change in availability of the given resource.

4. A method as set forth in claim 2 wherein said processors provide a read-modify-write instruction and wherein each of said lock data objects includes a latch data element which can be tested by said read-modify-write instruction.

5. A method as set forth in claim 4 wherein each of said resource data objects includes a latch data element which can be tested by said read-modify-write instruction.


Description

BACKGROUND OF THE INVENTION

The present invention relates to parallel processing systems and more particularly to a method for cooperatively managing resources on a system employing a group of processors, each of which is provided with a respective section of memory which is also accessible by other processors in the group.

When a variety of processes may be running simultaneously e.g., in a multi-tasking or time-sharing environment, it is known that some method or technique must be provided for preventing interference between different processes seeking access to the same resource. Resources may, for example, be files, portions of a data base, or physical entities such as a printer or display screen.

As is understood by those skilled in the art, the extent of access which one process requires with respect to a given resource, may change very frequently. This is done so that high level or exclusive levels of access are existent only for as short a time as possible, since high levels of access effectively exclude other processors. On the other hand, multiple processes can typically have simultaneous access at low levels, such as read only in the case of files.

In the prior art, various systems have been developed, such as file and record locking schemes, for implementing appropriate protections on single-processor systems. Certain locking schemes have also been extended to systems comprising small numbers of processors. For example, Digital Equipment Corporation of Maynard, Mass. provides a VMS lock manager system for protecting resources in its VAX line of computers when such computers are operated in clusters. Typically, however, the data managed by the lock manager system runs is tied to the memory of that one of the computers which first identified a given resource and processes running on other processors must access that data by means of a message passing scheme in order to effect any claim for access rights to the resource.

As will be perceived by those skilled in the art, a lock manager system which depends heavily on a single or master processor, will be very inefficient when the number of processors becomes large since the lock manager itself, together with its data, will be a hot spot or source of contention amongst various processes running on many different processors. Stated another way, such schemes do not permit linear growth or graceful scaling of performance in relation to the number of processors.

As is also understood, there is increasing interest in massively parallel processors, i.e. computer systems in which very large numbers of processors are employed, since it is increasingly difficult to improve the power or capability of single-processors due to physical limits.

Among the several objects of the present invention may be noted the provision of a novel method for managing resource in a multi-processor computer system, the provision of such a method which scales gracefully; the provision of such a method which operates effectively with relatively large numbers o processors; the provision of such a method in which resource management data is distributed over the system memory; the provision of such a method which automatically provides updated request status information to processors seeking a resource; the provision of such a method which is highly reliable, which operates effectively and which is of relatively simple and inexpensive implementation. Other objects and features will be in part apparent and in part pointed out hereinafter.

SUMMARY OF THE INVENTION

The computer method of the present invention cooperatively manages resources which may be needed by a variety of processes running essentially simultaneously on a group of processors each of which is provided with a respective section of memory which is also accessible by other processors in the group. A resource manager program is essentially replicated for each processor in its respective memory section. A hash table, used by the manager program, is divided into portions which are distributed over respective sections of the memory. The manager program implements a hashing algorithm which directs requests for access to designated resources to the same section of memory, irrespective of which processor originated the request.

Preferably, there is associated with each portion of the hash table, a plurality of resource data objects which can be assigned to named resources and which can record information regarding the processors which have access or have requested access to the respective resource and each section of the hash table includes a series of entries which provide pointers to respective linked lists of resource objects whose names hash to that entry.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagramatic illustration of a multi-processor computer architecture with which the resource management process of the present invention is useful;

FIG. 2 is a flow chart illustrating an initialization procedure which is implemented by the method of the present invention when a process requests a resource which operates under the management process;

FIG. 3 is a flow chart illustrating a procedure implemented when a process indicates that it wishes to convert its level of access to a resource;

FIGS. 4-9 are illustrations of data objects which implement the resource management functions of the present invention; and

FIG. 10 illustrates linkages between the elements of different types of data objects.

Corresponding reference characters indicate corresponding parts throughout the several views of the drawings.

DESCRIPTION OF THE PREFERRED EMBODIMENT

As indicated previously, the resource manager of the present invention is intended for use in connection with parallel processing systems employing large numbers of processors and particularly for use with such systems in which each processor is provided with a respective section of memory which is also accessible by other processors in the group. The particular embodiment of the invention disclosed herein is particularly adapted for operation on the TC2000 line of computers manufactured and sold by Bolt Beranek and Newman, Inc. of Cambridge, Mass., the assignee of the present application. These machines utilize the Motorola 88K line of microprocessors and the design of these machines is intended to permit up to 512 processors to be operated simultaneously. The operating system software provided with the computers allows processors to be assigned in groups or clusters to a given user application or group of applications To a substantial extent, each cluster may be treated as a separate computer with its own operating system. The operating system also provides for file handling and for mapping files into memory.

As do certain other multi processor systems, the TC2000 computers provide a read-modify-write memory operation which is performed as an atomic or uninterruptable operation. As is understood by those skilled in the art, such an operation allows a process to claim a data structure for excusive use while simultaneously checking to see that no other process has already claimed the data structure. For example, by setting a bit in a stored data word to a "1" (indicating claimed), the process will not distrub the setting if the bit was already a "1" but, at the same time, the requesting process can determine that the data structure was not claimed if the bit previously was a "0". This then can constitute a very basic latch or lock preventing interference between simultaneously running program segments. This basic latch type is used repeatedly in the more elaborate resource management method of the present invention. In the data structures described in greater detail hereinafter, the data providing this basic latch function is identified as a "SIMLATCH".

In FIG. 1, a group of processors are designated by reference characters 11A-11Z. Associated with each processor is a respective memory section, these memory sections being designated by reference characters 13A-13C. It has become conventional to refer to each processor and its respective memory section as a node. The processors and the respective memory sections are inter-connected through a switch matrix designated generally by reference character 15. The arrangement of the particular switch matrix employed in the TC2000 line of computers may be diagrammed in a manner which resembles a possible diagramming of the Fourier butterfly transform and this resemblance has given rise to the designation Butterfly for a predecessor line of computers employing a similar architecture.

The switch matrix 15 allows each processor to address, essentially directly, not only its respective memory section, but also all other memory sections, though addressing remote memory sections is somewhat slower than addressing local memory. Addressing of remote memory sections is essentially direct in that it does not require message passing or interruption of the processors corresponding to the remote memory. This computer architecture falls generally within the class of architectures which are described as NUMA, (non-uniform memory architectures). To provide graceful scaling of the resource management facilities provided by the method of the present invention, the data structures which are utilized by the management process, are distributed over the entire group of processors and their respective memory sections thereby minimizing, as completely as possible, unbalanced dependence on any given processor and its associated memory section.

At the outset, it should be understood that the resource managing method of the present invention is essentially consensual, that is, it does not enforce locks or deny access to resources. Rather, the method provides a set of tools or procedures which can be utilized by appropriately designed application programs to obtain shared access to resources without undue interference or contention.

The basic resource manager program is linked as a library to each application program which uses the resource manager and is loaded into the respective memory section for each processor. Application programs utilize the resource manager and the resources controlled thereby by making library function calls to the resource manager. The resource manager itself utilizes various types of data structures, these data structures being illustrated in FIGS. 4 through 9. At the outset, it is useful to describe these data objects in general terms and to indicate where they reside within the overall system. In FIGS. 4 through 9, the data elements in each object are given the same name as used in the source code appended to this specification and each name is followed with a brief description of the function provided by that data element.

NAMED MEMORY OBJECT

The Named Memory Object illustrated in FIG. 4 is a data object which is present only on Node 0 and as only a single instance. This object represents the very small amount of data which can be accessed by all of the copies of the memory management program, so as to determine that the various data structures have in fact been created and to determine the number of nodes which are participating in the cluster and like information.

NODE OBJECT

Each of the processors in the group will contain, in its respective memory section, an instance of a node object (FIG. 5) which stores data identifying the node and the cluster or group within which it resides, as well as data identifying the various processes which may be operating on the node.

HASH SEGMENT

Also present within the memory section for each node will be a respective segment or portion of a hash table which is distributed over the various nodes within the cluster or group. The hash table segment is illustrated in FIG. 6. As may be seen, the hash segment data object includes some small amount of data respecting the characteristics of the overall hash table together with a succession of entries (commonly called "buckets") which contain pointers to linked lists of resource data objects. Each list of resource data objects identifies those resources whose names hash to that entry. As indicated previously, neither the actual resources associated with each entry in the hash segment, nor the processors which may be needing those resources, need be directly associated with the node which stores the respective hash segment data object.

PROCESS OBJECT

A substantial number of process objects (FIG. 7) are allocated or assigned to each node so as to be available to processes running on the respective processor. The number of process objects on each node is a configuration parameter, preferably chosen larger than the number of processes which are likely to be simultaneously active on a given node and seeking managed resources. At this point, it should be noted that a single process may request access to multiple resources and thus, the process data object includes pointers to a queue of open locks and a queue of locks with pending call-backs as described hereinafter

RESOURCE OBJECT

The memory associated with each processor or node also contains or has allocated a plurality of resource data objects (FIG. 8). Again, the number of resource objects provided for is a configuration parameter, which is established taking into consideration the likely needs and demands of the user application programs which are to be running within the cluster. Each resource object, when utilized, is associated with an entry in the hash segment on the same node. A resource object is utilized when a process seeks to obtain access to a named resource and the name of the resource hashes to an entry in the hash segment data object on the node. An available resource object is assigned that name and is entered into the queue of resource object hashing to the hash segment entry as indicated previously. While the resource names should be unique, multiple names may hash to a single hash table entry. Access to a particular resource may be sought by a plurality of processes and, under certain circumstances, multiple accesses may be granted simultaneously. Accordingly, the data structure of the resource object contains data defining the level of granted access and the levels of requested accesses, as well as a list of queues of granted and requested accesses or locks.

LOCK OBJECT

A lock object links a single process object to a single resource object. Although, as stated previously, process objects can link to multiple resource objects and resource objects may be linked to multiple process objects, each link utilizes a separate lock object such as is illustrated in FIG. 9. Accordingly, the lock object data structure includes pointers to the owning process and to the resource to which the access relates, as well as various other values or parameters which are utilized by the resource manager program. Many of these other parameters are utilized in manipulating other lock objects when the level pertaining to a given lock object changes. During much of the functioning of the resource manager of the present invention, a particular process and a particular resource are linked essentially only through the lock object. In various of the data elements, the term "cookie" is used to designate identifying data, i.e. data which identified a requesting program object for callback or a resource object which is sought. FIG. 10 illustrates in somewhat simplified form, the nature of the links which may exist between data elements in a set of process, resource and lock data objects. FIG. 10 employs names for the various data elements which are somewhat more descriptive than the names used in the actual program source code and the following is a table for translating those names. 

    ______________________________________
    NODE              .fwdarw.
                              lmi.sub.-- node
    CID               .fwdarw.
                              i.sub.-- cid
    NID               .fwdarw.
                              i.sub.-- nid
    NODE COUNT        .fwdarw.
                              i.sub.-- numnodes
    PROCESS QUEUE     .fwdarw.
                              i.sub.-- procs
    NODE DIRECTORY    .fwdarw.
                              i.sub.-- nodepp
    HASH SIZES        .fwdarw.
                              i.sub.-- hash.i.sub.-- hashsize,
                              i.sub.-- hash.i.sub.-- nodesize,
                              i.sub.-- hash.i.sub.-- thissize
    HASH PTR          .fwdarw.
                              i.sub.-- hash.i.sub.-- hashp
    PROCESS           .fwdarw.
                              lmi.sub.-- proc
    PID               .fwdarw.
                              i.sub.-- pid
    CHECK             .fwdarw.
                              i.sub.-- check
    LOCK QUEUE        .fwdarw.
                              i.sub.-- locks
    CALLBACK QUEUE    .fwdarw.
                              i.sub.-- calls
    NODE ENTRY        .fwdarw.
                              i.sub.-- nodeq
    RESOURCE          .fwdarw.
                              lmi.sub.-- res
    NAME              .fwdarw.
                              i.sub.-- name
    GRANTED QUEUE     .fwdarw.
                              i.sub.-- granted
    REQUESTED QUEUE   .fwdarw.
                              i.sub.-- requested
    HASH ENTRY        .fwdarw.
                              i.sub.-- hashq
    LOCK              .fwdarw.
                              lmi.sub.-- lock
    RESOURCE PTR      .fwdarw.
                              i.sub.-- resp
    PROCESS PTR       .fwdarw.
                              i.sub.-- procp
    GRANTED           .fwdarw.
                              i.sub. -- level
    REQ STATUS        .fwdarw.
                              i.sub.-- req.sub.-- stat
    REQUESTED         .fwdarw.
                              i.sub.-- req.sub.-- level
    RESOURCE ENTRY    .fwdarw.
                              i.sub.-- resq
    PROCESS ENTRY     .fwdarw.
                              i.sub.-- procq
    CALLBACK ENTRY    .fwdarw.
                              i.sub.-- callq
    ______________________________________


As indicated previously, the resource manager of the present invention provides functionality substantially beyond simple record or file locking. In particular, the resource manager of the present invention provides a mechanism for shared consensual access to resources at various levels, some of which may coexist. While the different levels might accurately be described as levels of "access", they are conventionally referred to, for historical reasons, as levels of "lock". Accordingly, for purposes of present description, levels of lock should be understood as being essentially synonymous with levels of access.

The particular embodiment of the invention described herein provides for six levels of lock. These levels of lock may be described as follows:

LM.sub.-- NL--The null level serves as an indicator of interest and a place holder for future lock conversions, with no read or write access granted. Locks are opened at the null level.

LM.sub.-- CR--The concurrent read level provides shared read access to the resource, and allows sharing with other readers and concurrent writers. It is generally used for "unprotected" reads which allow simultaneous writes It can also be used in a hierarchical name locking scheme to mark the names on the rooted path to a name being locked for protected read; this keeps the ancestral names from being locked for protected write, while allowing "cousin names to still be locked for protected read or write. In this sort of hierarchical locking scheme, a protected read lock on an ancestral name allows all of its descendants to be read with protection without individually locking each descendant.

LM.sub.-- CW--The concurrent write level provides write access to the resource, and allows sharing with other concurrent readers and writers. It is generally used for "unprotected" writes which allow concurrent readers and writers, but no protected readers or writers. It can also be used in a hierarchical name locking scheme to mark the names on the rooted path to a name being locked for protected write; this keeps the ancestral names from being locked for protected read or write, while allowing "cousin" names to still be locked for protected read or write. In this sort of hierarchical locking scheme, a protected write lock on an ancestral name allows all of its descendants to be written with protection without individually locking each descendant.

LM.sub.-- PR--The protected read level provides a traditional shared read lock, allowing other readers but no writers.

LM.sub.-- PW--The protected write level provides a traditional write update lock, allowing concurrent readers, but no protected readers and no other writers.

LM.sub.-- EX--The exclusive level provides a traditional exclusive lock with write access, allowing no other readers or writers.

A lock is initially opened by lm.sub.-- open at LM.sub.-- NL, and the level can be changed using the lm.sub.-- convert function. In general, a resource can be locked at several levels at once. The following table summarizes the compatibility of the various lock levels. When a resource is already locked by some process at the "held" level, an attempt to get at the "get" level does the following: 

    __________________________________________________________________________
    held get .fwdarw.
             LM.sub.-- NL
                  LM.sub.-- CR
                       LM.sub.-- CW
                            LM.sub.-- PR
                                 LM.sub.-- PW
                                      LM.sub.-- EX
    __________________________________________________________________________
    LM.sub.-- NL
             succeeds
                  succeeds
                       succeeds
                            succeeds
                                 succeeds
                                      succeeds
    LM.sub.-- CR
             succeeds
                  succeeds
                       succeeds
                            succeeds
                                 succeeds
                                      blocks
    LM.sub.-- CW
             succeeds
                  succeeds
                       succeeds
                            blocks
                                 blocks
                                      blocks
    LM.sub.-- PR
             succeeds
                  succeeds
                       blocks
                            succeeds
                                 blocks
                                      blocks
    LM.sub.-- PW
             succeeds
                  succeeds
                       blocks
                            blocks
                                 blocks
                                      blocks
    LM.sub.-- EX
             succeeds
                  blocks
                       blocks
                            blocks
                                 blocks
                                      blocks
    __________________________________________________________________________


While the source code for the preferred embodiment of the computer resource managing method of the present invention, written in the C++programming language, is appended to this specification, the following description of the general mode of operation of the program will convey its essential nature.

An application program or constituent process thereof desiring to use a resource under the lock manager initially calls for the opening of a lock by issuing a lm.sub.-- open function call as referenced at 40 in FIG. 2. The resource manager program, upon receiving an lm.sub.-- open call, checks to see that the named memory object exists, as indicated at reference character 41. If the named memory object does not exist, an error code is returned as indicated at step 42. The program also checks to determine if a process object corresponding to the corresponding process already exists at step 45. As noted previously, a process can have locks open on many objects so the needed process object may already exist even though the application program is calling for the opening of a new lock. If the process object does not exist, an error code is returned as indicated at 47. Once the appropriate process object is determined to exist, the manager obtains a lock object from the pool of available lock objects as indicated at step 49.

As indicated previously, resources are named and the name of the sought resource is hashed to determine the appropriate entry into the hash table. This step is indicated at reference character 51. As noted previously, each copy of the resource manager program utilizes the same hashing algorithm so that a particular resource name will direct the program to the same portion of the hash table in the same section of memory, irrespective of which node initiated the inquiry.

As described previously, each entry in the hash table contains a pointer to a linked list of resource objects whose names hash to that entry. While the number of resource objects corresponding to each entry is preferably small, it will be understood by those skilled in the art that the nature of the hashing process necessarily allows that more than one resource object can exist for any hash table entry. The resources corresponding to each entry are stored as a doubly linked list. The resource manager program scans this list to determine if a resource object corresponding to the unique resource name and request already exists (step 53) and, if it does not, the resource object is created as indicated at step 55. The lock object is initially set at null level (NL) as indicated at step 57.

As indicated previously, cooperative application programs establish or set up locks relatively infrequently, e.g. typically only at the start and close respectively of a given process or program thread, but change level of lock frequently so as to minimize the time when a given resource is blocked for access by other processes which may be running essentially simultaneously on either the same or other nodes.

With reference to FIG. 3, the procedure for changing lock level is essentially as follows. Initially, the program must scan the queue of granted locks or accesses of the particular resource object to determine the state of accesses or locks already granted. From this information, the program determines whether the change or conversion sought is possible in accordance with table of permitted conversions given previously. If the change is possible, it is made as indicated at step 65.

Particularly if the change in level is to a lower level, the possibility of granting pending requests may be changed by the change in level implemented by the current call. Accordingly, the program scans the queue of requested converts corresponding to the particular resource object as indicated at step 67. If any of the requesting locks can be adjusted in status, these changes are made and the callback queue is similarly updated, this being indicated by reference character 69. The callback queue is available to be checked by processes which may have been previously blocked. Such processes may, for example, have been "put to sleep" under the control of their respective application programs but such processes are typically awakened periodically by the operating system so that they can check the status of the condition which caused the blocking. As will be understood by those skilled in the art, processes in multiprocessor environments may be blocked or put to sleep for various reasons, e.g. synchronization in addition to non-availability of resources such as are managed by the method of the present invention.

If the desired change in lock level is not possible, the requesting process is entered into the requested queue corresponding to the resource object. As indicated previously, the state of the entry in the requested queue may subsequently be altered by a change in the state of granted locks, e.g. an exclusive level lock may be lowered, and at such time the callback queue will also be changed so that the blocked process continue. If a given change is not possible, a program also updates the call back entries of the corresponding lock and process objects so that the blocked processes are notified of the fact.

As described previously, changes in level occur much more frequently than the opening and closing of locks. It is an important aspect of the present invention that the procedure for converting levels as described with reference to FIG. 3 does not require accessing of its corresponding portion of the hash table or obtaining any related data objects. Accordingly, changes in level are performed with relatively little machine time overhead as compared with the opening and closing operations.

The process for closing locks is essentially complementary to the process for opening locks and operates to restore the status of the involved data objects.

As indicated previously, the source code for one particular embodiment of the resource manager is appended to this specification. The program is written in multiple sections and subroutines and a brief description of each of these is as follows.

lockman.h--Contains definitions for public interface functions and interface structure definitions used by code outside the lock manager. This includes definitions of interface functions and their arguments, flags and option structures that can be passed to interface functions status and error code definitions, and status reporting functions and structures.

lm.sub.-- face.cxx--Contains the public interface functions called by code outside the lock manager. These interface functions generally do some argument validation and conversion, and then call C++methods on the underlying data objects to do the real work.

lmi.hxx--Contains internal definitions of the lock manager data structures and functions. The definitions of all the major internal data structures and methods that operate on them are here.

lmi.sub.-- mapmem.cxx--Contains C++methods for the named shared memory object. These are the methods used to attach and detach from a given named shared memory segment.

lmi.sub.-- node.cxx--Contains C++methods for the node object. There is a node object for each distinct processor/memory node on which the lock manager is being used. lmi.sub.-- hash.cxx Contains C++methods for the hash table object. There is a hash object in each node, to handle that node's share of the resource name hash table.

lmi.sub.-- proc.cxx--Contains C++methods for the process object. Storage for new process objects is kept in free lists on each node, and a new process object is allocated when a process attaches to the lock manager, and freed when it detaches All code that modifies a field of the process object is here.

lmi.sub.-- res.cxx--Contains C++methods for the resource object. Allocation and freeing of resources, conversions, and so forth are handled here. This code is also allowed to access fields in the lock object to expedite making changes to other locks when a lock level is changed.

lmi.sub.-- lock.cxx Contains C++methods for the lock object. Allocations and freeing of resources and interfaces to other lock operations are handled here. The resource methods are also allowed to work on lock objects, so much of the actual work is done in the resource methods.

lmi.sub.-- pool.cxx--Contains C++methods for storage pool and free list management. The node object contains free list pools of storage for new processes, resources, and locks.

lmi.sub.-- queue.cxx--Contains C++methods implementing queues as doubly linked lists. Many of the methods provide specialized services for particular queues and entries in queues.

lmi.sub.-- sim.cxx--Contains C++methods implementing the simple latches used to protect and synchronize parallel access to data structures.

lmi.sub.-- simwait.cxx--Contains functions that help to tune the spin loops used to implement simple latches.

realtime.hxx--Contains definitions for 64 bit realtime clock system service that returns current time in microseconds.

unsigned64.hxx--Contains C++definitions for unsigned 64 bit data class.

lmi.sub.-- unsigned64.c--Contains methods that implement unsigned 64 data class, for unsigned 64 bit arithmetic. This is used in implementing simple latches to measure the passage of real time using a system service that returns a 64 bit time in microseconds.

lmi.sub.-- md.c--Contains machine dependent helper functions for the lock manager library. These encapsulate the interface to the operating system services used.

lm.sub.-- msg.cxx--Contains functions and declarations related to lock manager status codes and error messages.

lm.sub.-- print.cxx--Contains debugging print functions for lock manager status structures.

lm.sub.-- prcookie.cxx--Contains the default print function for debugging printout of "cookies".

lm.sub.-- prendfun.cxx--Contains the default print function for debugging printout of completion function pointers.

lm.sub.-- prnotfun.cxx--Contains the default print function for debugging printout of blocking notify function pointers.

lm.sub.-- prvalp.cxx--Contains the default print function for debugging printout of user value buffer pointers.

lm.sub.-- rvalue.cxx--Contains the default print function for debugging printout of resource and lock value buffers.

lm.sub.-- checkp.cxx--Contains just the initialized global declaration for lm.sub.-- checkp.

In view of the foregoing it may be seen that several objects of the present invention are achieved and other advantageous results have been attained.

As various changes could be made in the above constructions without departing from the scope of the invention, it should be understood that all matter contained in the above description or shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense. ##SPC1##

«Previous Next»
Scheduling system for multiprocessor operating system Object transferring system and method in an object based computer operating system