Object Oriented Message Passing System and Method

1. Field of the Invention

The present invention relates generally to systems and methods for intra-computer communication, and more particularly to systems and methods for message-based client-server communication. Still more particularly, the present invention is an object oriented message passing system and method.

2. Description of the Background Art

In intra-computer communications, a client task requires a service provided by a server task. For example, a client task may require window creation or file deletion services. The particular service that the client task requires is performed by an appropriate server task, such as a window manager or a file system. A message is the unit of communication interchange between a client and a server. Thus, in order to inform a server that a particular service is required, the client task sends or issues an appropriate message. Upon receiving an issued message, the server task performs the required actions. Message passing systems and methods determine the manner in which a message that has been issued by a client task is delivered to a server task.

In the prior art, message passing systems and methods have relied upon a task-based message passing model, a port-based message passing model, or a port-set-based message passing model. Referring now to FIG. 1, a block diagram of a task-based message passing model is shown. In the task-based message passing model, when a client task requires a particular service, the client task sends a message directly to a server task that performs types of services related to the particular service required. Because multiple client tasks may require a service provided by the same server task, each server task present must support message queuing and message dispatch, both of which introduce an undesirable level of server task complexity. Moreover, because server tasks must support message queuing and message dispatch, memory beyond that required to implement a set of services must be available to each server task. An additional drawback associated with the task-based message passing model is that a client task and a corresponding server task are bound together in an inflexible manner, with each server task being dedicated to only one type of service. The inflexible binding found in the task-based message passing model also introduces an undesirable level of complexity when the behavior of the client task or the server task is to be modified or evolved.

Referring now to FIG. 2A, a block diagram of a port-based message passing model is shown. In the port-based message passing model, a message port represents a type of service available to a client task. Client tasks send messages to message ports rather than directly to server tasks. Messages sent to a given message port are queued within the message port by the operating system. Thus, to a server task, each message port represents a message queue. Multiple server tasks can compete to receive and process messages from any message port, thereby decoupling client tasks from server tasks. Client tasks commonly require many different types of services; hence, multiple message ports are required. Each message port requires a significant amount of memory to implement. Some prior art operating systems require that a unique port be present for each client task present.

Within a computer system, a message passing system generally resides within an operating system, which in turn resides within the computer system's memory. The total amount of memory available in the computer system is limited, and the memory must therefore be treated as a shared resource. It is thus highly desirable to have an operating system that occupies as little memory as possible. Message passing systems and methods that are based upon the port-based message passing model are undesirable because the memory required to implement each port significantly adds to the operating system's memory requirements. In personal computer systems, less memory is typically available than in other computer systems. Hence, message passing systems and methods that rely upon the port-based message passing model are particularly undesirable in personal computer systems.

Commonly, client tasks and server tasks function in different address spaces. In prior art message passing systems and methods that rely upon the port-based message passing model, when a client task and a server task operate in different address spaces, the message passing system or method must perform a mapping between address spaces prior to transferring a message from the client task to the server task. After the mapping between address spaces has been performed, the server task performs the required service. Often, particular services, such as input/output (I/O) operations, must be performed as rapidly as possible. The mapping between address spaces performed by prior art message passing systems and methods that rely upon the port-based message passing model undesirably increases the amount of time required to complete the service. Thus, prior art systems and methods that rely upon the port-based message passing model are undesirable in time-critical situations when client tasks and server tasks function in different address spaces.

Referring now to FIG. 2B, a block diagram of a port-set-based message passing model is shown. The port-set-based message passing model is a variant of the port-based message passing model described above. In the port-set-based message passing model, one or more message ports are associated to form a common port set. Each port set represents a particular type of service, and each individual message port represents a particular resource that can utilize the service associated with the port set to which it belongs. Client tasks therefore view individual message ports as resources to which messages can be sent. The additional level of structural granularity provided by the port-set-based message passing model significantly simplifies message decoding and message prioritization operations that must be performed by server tasks. As in the case of the port-based message passing model, however, each message port requires a significant amount of memory to implement. Therefore, message passing systems and methods that rely upon the port-set-based message passing model require even more memory than those that rely upon the port-based message passing model. Prior art message passing systems and methods that rely upon the port-set-based message passing model also suffer from the address space translation drawbacks described above in relation to the port-based message passing model.

What is needed is a means for message passing that provides a high level of structural granularity, that minimizes memory requirements, and that can reduce the time required to perform time-critical operations when client tasks and server tasks function in different address spaces.

The present invention is an object oriented message passing system and method. The system of the present invention comprises an object oriented message passing unit. The object oriented message passing unit creates and maintains a set of message objects and one or more port objects. Each message object is associated with a particular port object, and each message object represents a resource that corresponds to a service provided by a server task. Each port object represents a message receptacle from which a server task can receive messages. Message objects require significantly less memory to implement than port objects. Through the use of message objects and port objects, the present invention provides an object-oriented message passing model that exhibits a high level of structural granularity and that requires significantly less memory than any message passing model supported in the prior art.

The object oriented message passing unit associates an acceptance function with a port object upon request, where the acceptance function provides a means for performing one or more services within the context and address space of the client task. Acceptance functions significantly reduce the amount of time required to complete time-critical services by eliminating the need for mapping between address spaces and context switching.

A client task sends a message to a message object by issuing a send message request that includes a reference to a message object, a reference to a message, and a message type. The message referenced in the send message request itself indicates a required service. A server task receives a message from a port object by issuing a receive message request that includes a reference to a port object and a message type. In response to a send message request, the object oriented message passing unit creates a corresponding send message control block (MCB), where the send MCB includes the reference to the message. After creating the send MCB, the object oriented message passing unit first attempts to match the send message request with an acceptance function. If a matching acceptance function is present, the object oriented message passing unit ensures that the message referenced in the send MCB is transferred to the acceptance function. The acceptance function then performs the required service within the context and address space of the client task. If no matching acceptance function is present, the object oriented message passing unit matches the send message request to a receive message request. The object oriented message passing unit ensures that the message referenced in the send MCB is transferred to the server task that issued the receive message request, and provides any required mapping between address spaces. After the server task has received the message, the server task performs the required service.

Once an acceptance function or a server task has performed a required service, the acceptance function or the server task, respectively, preferably issues a reply to the message. The issuance of a send message request, followed by the matching of a send message request to an acceptance function or to a receive message request, followed by the issuance of a reply is referred to herein as a message transaction. In response to a reply, the object oriented message passing unit performs reply operations that deliver status information and possibly data to the client task that initiated the message transaction.

The object oriented message passing unit locks and unlocks message objects upon request. After a message object is locked, send message requests directed to the message object are not eligible to be matched to an acceptance function or to a receive message request until the message object is unlocked. Message object locking and unlocking provide a means to guarantee that a parameter value associated with a given message object remains unchanged while a message transaction is in progress.

The method of the present invention comprises the steps of: creating a port object; creating a message object associated with the port object; optionally associating an acceptance function with the port object; matching a send message request directed to the message object with the acceptance function or with a matching receive message request; matching a receive message request directed to the port object with a send message request; and performing reply operations following a server task's reply to a message.

FIG. 1 is a block diagram of a task-based message passing model of the prior art;

FIG. 2A is a block diagram of a port-based message passing model of the prior art;

FIG. 2B is a block diagram of a port-set-based message passing model of the prior art;

FIG. 3 is a block diagram of a preferred embodiment of the object oriented message passing system constructed in accordance with the present invention;

FIG. 4 is a block diagram of a preferred embodiment of an object oriented message passing unit in the system of the present invention;

FIG. 5 is a block diagram of an object oriented message passing model provided by the system of the present invention;

FIG. 6 is a block diagram of a preferred embodiment of a message object;

FIG. 7 is a block diagram of a preferred embodiment of a port object;

FIG. 8A is a block diagram of a synchronous send message control block in the present invention;

FIG. 8B is a block diagram of an asynchronous send message control block in the present invention;

FIG. 9A is a block diagram of a synchronous receive message control block in the present invention;

FIG. 9B is a block diagram of an asynchronous receive message control block in the present invention;

FIG. 10 is a block diagram of a delivery message control block in the present invention;

FIGS. 11A and 11B are a flowchart of a preferred object oriented message passing method in accordance with the present invention;

FIGS. 12A, 12B, and 12C are a flowchart of a preferred method for responding to a send message request in the present invention;

FIGS. 13A and 13B are a flowchart of a preferred method for responding to a receive message request in the present invention;

FIG. 14 is a flowchart of a preferred reply method in the present invention;

FIG. 15 is a flowchart of a preferred method for responding to a lock request in the present invention; and

FIG. 16 is a flowchart of a preferred method for responding to an unlock request in the present invention.

Referring now to FIG. 3, a block diagram of a preferred embodiment of an object oriented message passing system 10 constructed in accordance with the present invention is shown. The system 10 comprises a processing unit 12, an input device 14, an output device 16, an external storage device 18, and a memory 20 wherein an operating system 30, a client task 32, and a server task 34 reside. In the preferred embodiment, the operating system 30 is a microkernel operating system 30 capable of maintaining multiple address spaces. An object oriented message passing unit 40 resides within the operating system 30. Each element of the system 10 has an input and an output coupled to a common system bus 29. In an exemplary embodiment, the system 10 of the present invention is an Apple Macintosh computer system made by Apple Computer, Inc., of Cupertino, Calif., and having a Motorola MC68030 microprocessor and 8 Mbytes of Random Access Memory (RAM) wherein a microkernel operating system 30 that includes the object oriented message passing unit 40 resides.

In the present invention, a client task 32 is preferably a set of program instructions that requires a given service, for example, the creation of a window or the deletion of a file. The provider of a required service is referred to herein as a server task 34. Preferably, each server task 34 is also a set of program instructions. In the preferred embodiment, a given server task 34 can function as a client task 32 when the given server task 34 itself requires a particular service that is performed by another server task 34. The microkernel operating system 30 preferably maintains a task context for each client task 32 and each server task 34 in a conventional manner, where the task context is a set of data structures and information specific to the client or server task 34, 34 with which it is associated. The microkernel operating system 30 also preferably associates with each client task 32 and with each server task 34 an address space specifying a set of memory addresses accessible to the client task 32 and server task 34, respectively. Each address space preferably includes a microkernel-accessible address area that is common to all address spaces. A complete description of an exemplary microkernel operating system 30 and the functionality provided by the present invention is given in Appendix A.

The object oriented message passing unit 40 facilitates communication between client tasks 32 and server tasks 34. Referring now to FIG. 4, a block diagram of a preferred embodiment of the object oriented message passing unit 40 of the present invention is shown. The object oriented message passing unit 40 comprises an object management unit 42, a message transaction unit 44, a locking unit 46, and an object database 48. Each element of the object oriented message passing unit 40 has an input and an output coupled to the common system bus 29. In the preferred embodiment, the object oriented message passing unit 40 comprises computer program steps that are selectively executed by the processing unit 12.

The object management unit 42 creates and maintains data structures in the object database 48 that provide a client task communication interface between client tasks 32 and the object oriented message passing unit 40, and that provide a server task communication interface between server tasks 34 and the object oriented message passing unit 40. Through the client task communication interface and the server task communication interface, the object management unit 42 provides an object oriented message passing model 50. Referring now to FIG. 5, a block diagram of a preferred object oriented message passing model 50 provided by the present invention is shown. In the preferred object oriented message passing model 50, one or more message objects 52 form the client task communication interface, and one or more port objects 54 form the server task communication interface. Each message object 52 is associated with at least one client task 32. The set of client tasks 32 associated with a given message object 52 are referred to herein as a client team 33. Each message object 52 represents the behavior of a resource that is under the control of a given server task 34, and preferably reflects how client tasks 32 use a particular service provided by the server task 34. To invoke the behavior associated with a given message object 52, a client task 32 sends a message to the message object 52 by issuing a send message request, where each send message request specifies a message and a message type. The send message requests will be described in more detail below.

In the preferred object-oriented message passing model 50, each port object 54 serves as a receptacle for messages directed from client tasks 32 to message objects 52 that are associated with the port object 54. Server tasks 34 receive messages from a port object 54 by issuing receive message requests as will be described in more detail below. After receiving a given message, a server task 34 implements the behavior associated with the message object 52 to which the message was sent, according to details supplied in the message itself. The server task 34 then issues a reply to the given message that the client task 32 sent, where the reply provides the client task 32 with status information and possibly data. Herein, the sending of a given message by a client task, followed by a server task's receipt of the given message, followed by the server task's reply to the given message is referred to as a message transaction.

Referring now to FIG. 6, a block diagram of a preferred embodiment of a message object 52 is shown. The object management unit 42 creates a message object 52 and generates a unique message object identification (ID) in response to a server task's issuance of a message object creation request. The message object creation request preferably includes a reference constant specifying an initial state of the message object 52; a reference to a given port object 54 with which the message object 52 is to be associated; and a client team ID specifying a set of client tasks 32 with which the message object 52 is to be associated. Within each message object 52, a first data field stores the message object ID generated by the object management unit 42 that uniquely identifies the message object 52; a second data field stores the reference constant supplied by the server task, where the reference constant corresponds to the initial state of the message object 52; a third data field references the given port object 54 indicated in the message object creation request; a fourth data field specifies the client team ID included in the message object creation request; and a fifth data field references a next message object 52 associated with the given port object 54. The object management unit 42 does not assign a value to the fifth data field until a next message object 52 has been created.

Referring now to FIG. 7, a block diagram of a preferred embodiment of a port object 54 is shown. The object management unit 42 creates a port object 54 and generates a unique port object ID in response to a port object creation request from a server task 34. In the port object 54, a first data field specifies a next port object and a previous port object. The object management unit 42 therefore links port objects 52 together via their respective first data fields. A second data field in the port object 54 provides a list of those message objects 52 that are associated with the port object 54. When the object management unit 42 creates a new message object 52, the object management unit 42 adds the corresponding new message object ID to the list in the second data field of the port object 54 with which the newly created message object 52 is associated. A third data field in the port object 54 provides a list of each associated message object 52 that has been "locked" in response to a lock request. When a given message object 52 is locked, any send message requests issued by client tasks 32 and directed to the given message object 52 are not available to be received by a server task 34 until unlocking operations have been performed. Message object locking and unlocking operations are performed by the locking unit 46 and will be described in detail below.

In the port object 54, a fourth data field is used to store a pending send message list that specifies those message that client tasks 32 have sent to a message object 52 associated with the port object 54, but that have not yet been received by a server task 34. A fifth data field in the port object 54 is used to store a pending receive message list that specifies those receive message requests that have been issued to the port object 54 by server tasks 34, but that have not yet been matched to a corresponding message sent by a client task 32. A sixth data field in the port object 54 is used to store a pending reply message list that specifies each message that server tasks 34 have received but for which a reply has not yet been issued. When the object management unit 42 creates the port object 54, the fourth, fifth, and sixth data fields are empty. As will be described below, the lists stored in the fourth, fifth, and sixth data fields are maintained by the message transaction unit 44.

A seventh data field in the port object 54 optionally specifies an acceptance function. The acceptance function comprises a set of instructions that directly implements a subset of services provided by a server task 34 within the task context of a client task 32. The acceptance function uses the microkernel-accessible address area that is common to the address space of the client task 32, and therefore effectively functions within the address space of the client task 32. Acceptance functions thus eliminate the need for context switching and mapping between address spaces. Performance of a given service via an acceptance function therefore requires much less computational time than performance of the same service via a server task 34. Acceptance functions provide a means for minimizing the amount of time required to perform time-critical operations. The seventh data field in the port object 54 also specifies a set of message types for which the acceptance function is capable of providing a service. Preferably, the seventh data field is empty when the object management unit 42 first creates the port object 54. The object management unit 42 stores or registers a reference to an acceptance function and the set of message types in response to a server task registration request that identifies a particular acceptance function and the set of message types.

In an exemplary situation in which acceptance functions might be used beneficially, disk input/output (I/O) operations may require services provided by a first server task 34 associated with a file system. The first server task 34 may selectively require particular services provided by a second server task 34 associated with a disk driver, which may in turn selectively require particular services provided by a third server task 34 associated with a small computer systems interface (SCSI) manager. If the second server task 34 and the third server task 34 issue appropriate registration requests, the object management unit 42 will register an acceptance function for the second server task 34 and an acceptance function for the third server task 34, respectively. Those disk I/O operations that require the particular services corresponding to the acceptance functions registered will occur within the task context and within the address space of the first server task 34, eliminating the need for mapping between address spaces and context switching. This in turn will greatly reduce the time required to perform these disk I/O operations.

In the preferred embodiment, client tasks 32 can send messages synchronously or asynchronously. In a like manner, server tasks can issue message receive requests synchronously or asynchronously. Synchronous and asynchronous operations will be described in more detail below. An eighth data field in the port object 54 specifies an amount of storage available for messages sent asynchronously, and a ninth data field in the port object 54 specifies an amount of storage available for asynchronous message receive requests.

A tenth data field in the port object 54 is used to store the unique port object ID generated by the object management unit 42. Finally, an eleventh data field in the port object 54 is used to store statistical information such as the total number of messages sent to message objects 52 associated with the port object 54 since the port object's creation. In the preferred embodiment, each message object 52 is associated with a particular port object 54. Therefore, a port object 54 must be created in the preferred embodiment before a corresponding message object 52 is created.

In addition to creating message objects 52 and port objects 54, the object management unit 42 provides to a server task 34 information associated with a given message object 52 in response to a message object examination request. The information provided includes the client team ID specified in the given message object, a port object ID specifying the port object 54 with which the given message object 52 is associated, and the current value of the message object's reference constant. The object management unit 42 extracts the client team ID and the current value of the reference constant from the message object 52 itself, and uses the port object address within the message object 52 to retrieve the port object ID from the port object 54 with which the message object 52 is associated. The object management unit 42 also modifies the above information in response to a message object modification request, and deletes a given message object 52 in response to a client team termination message. In a manner analogous to the operations provided for message objects 52, the object management unit 42 provides information related to a port object 54 in response to a port object examination request from a server task 34, modifies data fields within the port object 54 in response to a port object modification request, and deletes port objects 52 in response to a port object deletion request.

In the preferred embodiment, the object management unit 42 can associate multiple message objects 52 with a single port object 54. The memory storage requirements for each message object 52 are significantly less than the memory storage requirements for each port object 54. In an exemplary embodiment, each port object 54 occupies 128 bytes within the memory 20, while each message object occupies as little as 24 bytes. In the present invention, because a given server task 34 can register an acceptance function that is to provide one or more services, the given server task 34 is simpler and requires less memory to implement. Moreover, because an acceptance function executes within the task context of a client task 32, no additional memory is required for context switching when an acceptance function performs a service. Thus, the object oriented message passing model 50 provided by the present invention requires significantly less memory space than that required by any message passing model provided by prior art message passing systems, while providing a higher level of structural granularity for a given amount of available memory.

The message transaction unit 44 performs the operations required to carry out message transactions. In particular, the message transaction unit 44 performs the operations required to support the sending of messages to message objects 52 from client tasks 32, the issuance of receive message requests by server tasks 34, the matching of messages sent to issued receive message requests, the selective delivery of a message to an acceptance function or to a server task 34 to perform a service indicated by a message, and the transfer of replies from acceptance functions and server tasks 34 to client tasks 32.

The message transaction unit 44 requires that client tasks 32 send messages to message objects 52 by issuing send message requests. In the preferred embodiment, each send message request is either 1) a synchronous send message request; 2) a synchronous send-and-receive message request; 3) an asynchronous send message request; or 4) an asynchronous send-and-receive message request. As will be described in detail below, in response to either type of synchronous send message request, the message transaction unit 44 blocks the client task 32 until the message transaction has completed, thereby preventing the client task 32 from performing other operations while the message transaction is in progress. In contrast, the message transaction unit 44 allows the client task 32 to continue other operations in response to either type of asynchronous send message request. Each type of send message request preferably specifies a message object ID; a reference to a starting memory location at which a message begins; message length information; a message type that provides a categorization of the message; send options that indicate whether the message is to be delivered to an acceptance function or to a server task 34 by reference or by value; and a flag to indicate whether the message object 52 to which the send message request is directed is to be locked in response to the send message request and subsequently unlocked after an acceptance function or a server task 34 has replied to the message. Both synchronous and asynchronous send-and-receive message requests additionally specify a reply buffer address at which a server task can store a reply message or data, and a reply buffer size. In the preferred embodiment, the message type is a 32-bit number.

Each type of synchronous send message request also specifies a maximum time interval that the client task 32 can remain idle while the message transaction occurs. In addition to the information common to every send message request, each type of asynchronous send message request additionally specifies an address at which the message transaction unit 44 can store a message ID signal corresponding to the asynchronous send message request, and event notification information that indicates how the message transaction unit 44 is to notify the client task 32 when the message transaction is complete. In the description that follows, the message ID signal is simply referred to as the message ID.

In response to a given client task's issuance of a send message request, the message transaction unit 44 creates a send message control block (MCB) according to whether the send message request is synchronous or asynchronous. In response to a synchronous send message request or a synchronous send-and-receive message request, the message transaction unit 44 creates a synchronous send MCB 60. Referring now to FIG. 8A, a block diagram of a preferred embodiment of a synchronous send MCB 60 is shown. The synchronous send MCB 60 is a data structure including a first data field specifying the message object ID corresponding to the message object 52 to which the synchronous send message is directed; a second data field providing the port object ID identifying the port object 54 with which the message object 52 specified in the first data field is associated; a third data field providing a reference to a next and to a previous entry in the port object's pending send message list; a fourth data field specifying the client task ID corresponding to the client task 32 that issued the synchronous send message request; a fifth data field providing the starting address in the memory 20 at which an associated message is stored; a sixth data field providing the length of the message; a seventh data field indicating the message type specified in the synchronous send message request; an eighth data field wherein the message ID is stored; a ninth data field specifying the send options indicated in the synchronous send message request; a tenth data field that the message transaction unit 44 uses to reference an MCB corresponding to a matching receive message request; an eleventh data field in which the message transaction unit 44 stores a server task ID after delivering the message to a server task 34; a twelfth data field indicating whether the message corresponding to the synchronous send message request has been delivered to a server task; a thirteenth data field indicating whether the message object 52 identified in the synchronous send request is locked; a fourteenth data field specifying the address of a reply buffer in the event that the send message request is a synchronous send-and-receive message request; a fifteenth data field providing a reply buffer size in the event that the send message request is a synchronous send-and-receive message request; a sixteenth data field indicating whether the sending client task 32 has been blocked as a result of a blocking request; and a seventeenth data field specifying the maximum time interval that the sending client task 32 can remain idle during the message transaction. The message transaction unit 44 stores the synchronous send MCB 60 in the object database 48.

If the send message request is an asynchronous send message request or an asynchronous send-and-receive message request, the message transaction unit 44 creates an asynchronous send MCB 62 rather than a synchronous send MCB 60. Referring now to FIG. 8B, a block diagram of an asynchronous send MCB 62 is shown. The asynchronous send MCB 62 is a data structure including a first through a fifteenth data field, each of which specifies information analogous to that specified in the first through fifteenth data fields in the synchronous send MCB 60 described above. In addition, the asynchronous send MCB 62 includes a sixteenth data field wherein the message transaction unit 44 stores the event notification information specified in the asynchronous send message request or asynchronous send-and-receive message request. As in the case of the synchronous send MCB 60, the message transaction unit 44 stores the asynchronous send MCB 62 in the object database 48.

The message transaction unit 44 requires that a server task 34 issue a receive message request to receive a message from a given port object 54. Receive message requests are either synchronous receive message requests, or asynchronous receive message requests. Each type of receive message request specifies a port object 54; a message type indicating a category of message the server task 34 is to receive; a reference to a memory location at which a message buffer begins; and a message buffer size. In the preferred embodiment, the message type is a 32-bit number. A synchronous receive message request further includes a maximum time interval the issuing server task 34 can remain idle prior to the delivery of a message by the message transaction unit 44. In addition to the information common to both synchronous and asynchronous receive message requests, an asynchronous receive message request further specifies a message address at which a receive ID corresponding to the asynchronous receive message request can be stored; and event notification information that the message transaction unit 44 uses to notify the issuing server task 34 that a message corresponding to the asynchronous receive message request has been delivered.

In response to a receive message request, the message transaction unit 44 creates a receive MCB if no send MCB having a message type that matches the message type given in the receive message request is present. In other words, the message transaction unit 44 creates a receive MCB if the receive message request cannot be immediately matched to a previously-issued send message request. The receive MCB created by the message transaction unit is either a synchronous or an asynchronous receive MCB 70, 72, according to whether the receive message request is a synchronous or an asynchronous receive message request, respectively. Referring now to FIG. 9A, a block diagram of a preferred embodiment of a synchronous receive MCB 70 is shown. The synchronous receive MCB 70 is a data structure including a first data field specifying the port object ID corresponding to the port object 54 to which the synchronous receive message request is directed; a second data field referencing a next and a previous entry in the pending receive message list of the port object 54 indicated in the first data field; a third data field wherein the message transaction unit 44 stores a server task ID corresponding to the server task 34 that issued the request; a fourth data field specifying the message buffer address included in the synchronous receive message request; a fifth data field specifying the message buffer size contained in the synchronous receive message request; a sixth data field providing the message type included in the synchronous receive message request; a seventh data field that the message transaction unit 44 uses to reference an MCB corresponding to a send message request that matches the synchronous receive message request according to message type; and an eighth data field wherein the message transaction unit 44 stores the maximum time interval the issuing server task 34 can remain idle as specified in the synchronous receive message request. The message transaction unit 44 stores the synchronous receive MCB 70 in the object database 48.

Referring now to FIG. 9B, a block diagram of a preferred embodiment of an asynchronous receive MCB 72 is shown. The asynchronous receive MCB 72 is a data structure including a first through a seventh data field that specify information analogous to that detailed for the synchronous receive MCB 70. The asynchronous receive MCB 72 also includes an eighth data field wherein the message transaction unit 44 stores the receive ID, and a ninth data field wherein the message transaction unit 44 stores the event notification information specified in the asynchronous receive message request. As in the case of each synchronous receive MCB 70, the message transaction unit 44 stores each asynchronous receive MCB 72 in the object database 48.

In the preferred embodiment, each MCB described above 60, 62, 70, 72 is implemented as a general MCB structure (not shown) plus one or more data fields that supply request-specific information. The general MCB structure includes data fields for specifying a port object 54; a client or server task 32, 34; references to other corresponding MCB structures; and state information specifying whether the general MCB structure corresponds to a synchronous or asynchronous request and whether the general MCB structure corresponds to a send or receive request. Those skilled in the art will be able to determine the specific additional data fields necessary to implement a synchronous MCB 60, an asynchronous send MCB 62, a synchronous receive MCB 70, and an asynchronous receive MCB 72 according to the descriptions provided above.

The message transaction unit 44 selectively matches a receive message request with a send message request, and selectively matches a send message request either with an acceptance function or a receive message request. Matching occurs according to the message types specified in a send message request and a receive message request, or according to the message type specified in a send message request and the set of message types associated with an acceptance function. In the preferred embodiment, the message transaction unit 44 performs a logical AND operation to determine whether message types match.

In response to a given send message request, the message transaction unit 44 may determine that the send message request can be immediately serviced by a matching acceptance function or that the send message request can be immediately serviced by a matching pending receive message request. The message transaction unit 44 may also determine that the send message request cannot be immediately serviced and must therefore become a pending send message request. The message transaction unit 44 categorizes the send message request as pending by inserting a reference to the corresponding send MCB into the pending send message list of the port object 54 identified in the send MCB. The message transaction unit 44 preferably maintains the pending send message list of the port object 54 as a doubly-linked list in first-in first-out (FIFO) order.

In response to a given receive message request, the message transaction unit 44 may determine that the receive message request can be immediately matched to a pending send message request; or that the receive message request cannot be immediately matched to a send message request and must therefore become a pending receive message request. The message transaction unit 44 categorizes a receive message request as pending by creating a receive MCB and by inserting a reference to the corresponding receive MCB in the pending receive message list of the port object 54 identified in the receive MCB. As with the pending send message list, the message transaction unit 44 preferably maintains the pending receive message list as a doubly-linked list in FIFO order. When the message transaction unit 44 categorizes a synchronous receive message request as pending, the message transaction unit 44 also blocks the execution of the server task 34 that issued the synchronous receive message request until a matching send message request arrives.

The detailed operations that are performed by the message transaction unit 44 in response to send message requests and receive message requests are now considered. The detailed operations are also discussed as individual method steps in FIGS. 11 through 16.

Send Message Requests

In response to a send message request, the message transaction unit 44 initially decodes the message object ID specified in the send message request. If the message object ID is invalid, the message transaction unit 44 issues an invalid ID error to the client task 32 that issued the send message request, and does not further consider the send message request. If the send message request specifies a valid message object ID, the message transaction unit 44 next obtains the address of the port object 54 with which the message object 52 is associated from the message object's fourth data field. By inspecting the list of locked message objects within the port object 54 specified at the port object address obtained, the message transaction unit 44 next determines whether the send message request is directed to a locked message object 52. If the message object 52 is locked, the message transaction unit 44 blocks the client task 32 that issued the send request until the message object 52 is unlocked by preventing the client task 32 from performing further operations. If the message object 52 is not locked, or after the message object 52 is unlocked, the message transaction unit 44 inspects the send message request and determines if the message object 52 is to be locked in response to this send message request. If the message object 52 is to be locked, the message transaction unit 44 issues a lock request to the locking unit 46, which performs the required locking as will be described in detail below.

After any required message object locking has been performed, the message transaction unit 44 generates a unique message ID signal, referred to herein as the message ID, to correspond to the message transaction initiated by the send message request. The message transaction unit 44 then creates a synchronous send MCB 60 or an asynchronous send MCB 62 according to whether the send message request is synchronous or asynchronous, respectively. The message transaction unit 44 associates the send MCB with the message ID, such that the send MCB can be uniquely identified and located by the message ID. When the message transaction unit 44 creates the send MCB, the message transaction unit 44 preferably indicates via the fourteenth data field in the send MCB whether the message object 52 to which the send message request is directed has been locked in response to the send message request. After the send MCB has been created, the message transaction unit 44 determines whether an acceptance function has been registered in the port object 54 associated with the message object 52 to which the send message request was directed. Preferably, the message transaction unit 44 determines whether an acceptance function has been registered by inspecting the port object's seventh data field. The message transaction unit 44 then compares the message type indicated in the send message request with the each message type within the set of message types specified in the port object's seventh data field, thereby determining whether the acceptance function is applicable to the send message request. In the preferred embodiment, each comparison is made through a logical AND operation. If a message type match occurs, the message transaction unit 44 creates a delivery MCB 80 using information specified in the send MCB.

Referring now to FIG. 10, a block diagram of a preferred embodiment of a delivery MCB 80 is shown. The delivery MCB 80 is created from a subset of the data fields within the send MCB. The delivery MCB 80 includes a first data field in which the message ID specified in the send MCB is stored; a second data field specifying the reference constant of the message object 52 specified in the send MCB; a third data field in which the send options specified in the send MCB are stored; a fourth data field providing the message type given in the send MCB; a fifth data field in which the message location specified in the send MCB is stored; a sixth data field in which the message length specified in the send MCB is stored; a seventh data field in which any reply buffer address specified in the send MCB is stored; and an eighth data field in which any reply buffer size specified in the send MCB is stored. Preferably, when a matching acceptance function is present, the message transaction unit 44 creates and stores the delivery MCB 80 in the microkernel-accessible address area within the client task's address space. After creating the delivery MCB 80, the message transaction unit 44 transfers the location of the delivery MCB 80 to the acceptance function. The acceptance function subsequently obtains the message specified within the delivery MCB 80 and performs the service indicated by the message. The acceptance function executes within the task context and address space of the client task 32 that issued the send message request. In the preferred embodiment, the acceptance function can return a notification to the message transaction unit 44 indicating that the required service is in progress and that a reply will be issued upon completion of the service. If an acceptance function completes a service without explicitly issuing a reply, the message transaction unit 44 automatically issues a reply on behalf of the acceptance function, thereby providing the client task 32 that issued the send message request with status information and possibly data.

The message transaction unit 44 next sets the delivery status specified in the send MCB to indicate that the message has been delivered. The message transaction unit 44 then inserts a reference to the send MCB at the end of the port object's pending reply message list. The pending reply message list indicates those messages that have been received either by an acceptance function or a server task 34 but that have not been issued a reply. In the preferred embodiment, the message transaction unit 44 maintains the pending reply message list as a doubly-linked list arranged in FIFO order.

After inserting the reference to the send MCB in the pending reply message list, the message transaction unit 44 returns the message ID to the client task 32 that issued the send message request if the send MCB is an asynchronous send MCB 62. If the send MCB is a synchronous send MCB 60, the message transaction unit 44 blocks the operation of the client task 32 until the acceptance function either issues a reply to the message specified in the delivery MCB 80 or completes the required service without issuing a reply. If the maximum time interval is exceeded while the client task 32 is blocked, the message transaction unit 44 returns a timeout status to the client task 32 and informs the acceptance function that the message is to be canceled. Once the acceptance function has issued a reply or has completed the required service, the message transaction unit 44 performs reply operations as will be detailed below.

If the message transaction unit 44 determines that an acceptance function capable of servicing the send message request is not present, the message transaction unit 44 subsequently determines whether a receive MCB having a message type that matches that specified in the send message request is referenced in the port object's pending receive message list. If a matching receive MCB exists, the message transaction unit 44 inserts a reference to the matching receive MCB in the tenth data field in the send MCB. In a like manner, the message transaction unit 44 inserts a reference to the send MCB in the seventh data field of the matching receive MCB. Next, the message transaction unit 44 creates a delivery MCB 80 at the message buffer address specified in the receive MCB. The message transaction unit 44 then inserts a reference to the send MCB into the pending reply message list within the port object 54 specified in the send MCB. Next, the message transaction unit 44 determines whether the receive MCB is a synchronous receive MCB 70 or an asynchronous receive MCB 72. If the receive MCB is a synchronous receive MCB 70, the message transaction unit 44 unblocks the server task 34 that issued the synchronous receive message request. The message transaction unit 44 then deletes the synchronous receive MCB 70.

If the message transaction unit 44 determines that the receive MCB is an asynchronous receive MCB 72, the message transaction unit 44 transfers the message referenced in the send MCB to a region within the message buffer referenced by the asynchronous receive MCB 72. The message transaction unit 44 supports the transfer of messages by reference or by value, and also performs any required mapping between address spaces. In the preferred embodiment, the message transaction unit 44 transfers the message by calling a message delivery function. Next, the message transaction unit 44 notifies the server task 34 that issued the asynchronous receive message request according to the event notification information provided in the asynchronous receive MCB 72. Following the notification of the server task 34, the message transaction unit 44 deletes the asynchronous receive MCB 72.

After the deletion of the synchronous receive MCB 70 or the asynchronous receive MCB 72, the message transaction unit 44 returns the message ID to the client task 32 that issued the send message request if the send MCB is an asynchronous send MCB 62. If the send MCB is a synchronous send MCB 60, the message transaction unit 44 blocks the operation of the client task 32 by preventing the client task 32 from performing further operations.

If the message transaction unit 44 determines that no matching acceptance function and no matching receive MCB exists for the send message request, the message transaction unit 44 inserts a reference to the send MCB in the pending send message list of the port object 54 specified by the send message request. The pending message send list thus specifies each send message request that has not yet been matched to a corresponding receive message request. Following the insertion of the reference to the send MCB into the pending send message list, the message transaction unit 44 returns the message ID to the client task 32 that issued the send message request if the send MCB is an asynchronous send MCB 62. If the send MCB is a synchronous send MCB 60, the message transaction unit 44 blocks the client task 32 by preventing the client task 32 from performing further operations.

Receive Message Requests

In response to a receive message request, the message transaction unit 44 first decodes the port object ID specified in the receive message request. Next, the message transaction unit 44 determines whether the port object ID identifies an existing port object 54. If the port object ID does not identify an existing port object 54, the message transaction unit 44 returns an invalid ID error to the server task 34 that issued the receive message request, and does not consider the receive message request further. If the port object ID identifies an existing port object 54, the message transaction unit 44 determines whether a send MCB having a message type matching that specified in the receive message request is present in the port object's pending send message list. If no matching send MCB is present, the message transaction unit 44 next creates an appropriate type of receive MCB as described above to correspond to the receive message request. The message transaction unit 44 also inserts a reference to the receive MCB in the port object's pending receive message list. If the receive MCB created is an asynchronous receive MCB 72, the message transaction unit 44 does not perform additional operations. If the receive MCB created is a synchronous receive MCB 70, the message transaction unit 44 blocks the server task 34 that issued the synchronous receive message request until a matching send message request arrives. If the maximum time interval specified in the synchronous receive message request is exceeded while the server task 34 is blocked, the message transaction unit 44 returns a timeout status to the server task 34, and cancels the synchronous receive message request by deleting the synchronous receive MCB 70 created.

When a matching send message request arrives, the message transaction unit 44 creates the appropriate type of send MCB, and then inserts a reference to the matching send MCB in the receive MCB's seventh data field, and inserts a reference to the receive MCB in the tenth data field of the matching send MCB. The message transaction unit 44 then inserts a reference to the send MCB in the pending reply message list in the port object 54. After inserting the reference to the send MCB in the pending reply message list, the message transaction unit 44 creates a delivery MCB at the message buffer address specified in the receive MCB. If the receive MCB is an asynchronous receive MCB 72, the message transaction unit 44 notifies the server task 34 that issued the asynchronous receive message request according to the event notification specified in the asynchronous receive MCB 72. The message transaction unit 44 then delivers the message referenced in the send MCB to the server task 34 within the message buffer indicated in the asynchronous receive MCB 72, according to the send options specified in the matching send MCB. In the preferred embodiment, the message transaction unit 44 supports the delivery of messages by reference or by value, and performs any required mapping between the client task's address space and the server task's address space. To deliver the message, the message transaction unit 44 preferably calls a message delivery function. Following the delivery of the message, the message transaction unit 44 deletes the receive MCB that had been created and removes the reference to the receive MCB from the pending receive message list.

If the receive MCB created is a synchronous receive MCB 70, the message transaction unit 44 unblocks the server task 34 rather than notifying the server task 34 as described above. After unblocking the server task 34, the message transaction unit 44 performs the same message delivery and receive MCB deletion operations as described above.

If the message transaction unit 44 determines that a matching send MCB is present in the pending send message list immediately after determining that the port object ID is valid, the message transaction unit 44 does not create a receive MCB. Rather, the message transaction unit 44 inserts a reference to the matching send MCB in the pending send message list, and then creates a delivery MCB as described above. If the receive message request is an asynchronous receive message request, the message transaction unit 44 next notifies the server task 34 according to the event notification information specified in the matching send MCB. If the receive message request is a synchronous rather than an asynchronous receive message request, the message transaction unit 44 does not have to perform an unblocking operation as described above because the server task 34 had not been blocked. Regardless of the type of receive message request, the message transaction unit 44 next delivers the message referenced in the send MCB to the message buffer specified in the receive message request, according to the send options specified in the send MCB.

After a server task 34 has performed the service indicated by a message, the server task 34 issues a reply to the message. After an acceptance function has performed a service indicated by a message, the acceptance function may explicitly issue a reply to the message. If the acceptance function does not explicitly issue a reply, the message transaction unit 44 automatically issues a reply on behalf of the acceptance function after execution of the acceptance function has completed. In the preferred embodiment, a reply includes the message ID and status information. The reply may also include a reference to a reply buffer. In response to a reply, or when issuing a reply on behalf of an acceptance function, the message transaction unit 44 decodes the message ID specified in the reply to locate the appropriate send MCB. Next, the message transaction unit 44 delivers the status information to the client task 32 specified in the send MCB. If a reply buffer is indicated in the reply, the message transaction unit 44 delivers a copy of the contents of the reply buffer to the client task 32. The message transaction unit 44 then issues an unlock request to the locking unit 46 if the fourteenth data field in the send MCB indicates that the message object 52 had been locked in response to the client task's send message request. Message object unlocking will be described in detail below. Next, the message transaction unit 44 deletes the message ID, and finally deletes the send MCB. The message transaction that had been associated with the message ID is now complete.

Preferably, server tasks 34 issue receive message requests on a periodic basis, or immediately following the performance of a service. This ensures that server tasks 34 do not remain idle and also guarantees that each send message request issued by a client task 32 will be serviced by a server task 34. In the preferred embodiment of the present invention, in response to a receive-and-reply message request issued by a server task 34, the message transaction unit 44 performs reply operations associated with the reply portion of the receive-and-reply message request, and immediately thereafter responds to the receive portion of the receive-and-reply message request. Preferably, the receive-and-reply message request includes the information separately specified above for receive message requests and for reply operations. The message transaction unit 44 functions according to the above descriptions when performing the reply operations and when responding to the receive portion specified in the receive-and-reply request. Because the message transaction unit 44 supports receive-and-reply message requests, the message transaction unit 44 ensures that each server task 34 is utilized as efficiently as possible.

The locking unit 46 performs message object locking and unlocking operations. Send message requests directed to a particular message object 52 after the message object 52 has been locked are not eligible to be matched to an acceptance function or to a receive MCB until unlocking operations have been performed. The locking unit 46 performs locking operations in response to a lock request. In the preferred embodiment, lock requests can be issued by a server task 34, or by the message transaction unit 44 on behalf of a client task 32 as a result of a send message request. Preferably, each lock request specifies the message object ID of a message object 52 targeted for locking.

In response to a lock message object request, the locking unit 46 determines if the message object ID specified is valid. If the message object ID is not valid, the locking unit 42 returns an invalid ID error to the issuer of the lock message object request, and does not consider the request further. If the message object ID is valid, the locking unit 46 determines if the targeted message object 52 is already locked by inspecting the list of locked message objects within the port object 54 with which the targeted message object 52 is associated. In the preferred embodiment of the present invention, each element in the list of locked message objects is a lock structure that specifies a message object ID and a semaphore. If the targeted message object 52 is referenced in the list of locked message objects, the targeted message object 52 is already locked. Preferably, the semaphore provides a lock wait list that sequentially indicates each task that is waiting to lock the targeted message object 52 in FIFO order.

If the locking unit 46 determines that the targeted message object 52 is already locked, the locking unit 46 adds the ID of the client task 32 or server task 34 responsible for initiating the lock request to the end of the lock wait list. The locking unit 46 then waits until the currently-considered client task ID or server task ID is at the front of the lock wait list and a corresponding unlocking request directed to the targeted message object 52 has been received. The locking unit 46 then performs unlocking operations as will be described below.

If the message object 52 is not already locked, the locking unit 46 inspects the pending reply message list within the port object 54 to determine how many send message control blocks currently referenced specify the targeted message object 52. If no send MCB referenced specifies the targeted message object 52, the locking unit 46 inserts a new lock structure containing the targeted message object ID into the list of locked message objects, thereby locking the targeted message object 52. Once the targeted message object 52 is locked, the client task 32 or the server task 34 associated with the locked message object 52 is referred to herein as the "owner" of the targeted message object's lock. After locking the targeted message object 52, the locking unit 46 returns control to the issuer of the lock request.

If one or more send message control blocks currently referenced in the pending reply message list specify the targeted message object 52, the locking unit waits until the reference to each such send MCB has been removed from the pending reply message list due to a reply or a message cancellation. After the reference to each send MCB that specifies the targeted message object 52 has been removed from the pending reply message list, the locking unit 46 inserts a new lock structure containing the targeted message object ID into the list of locked message objects, thereby locking the targeted message object 52. After locking the targeted message object 52, the locking unit 46 returns control to the issuer of the lock request. While the reference to each send MCB that specifies the targeted message object 52 is being removed from the pending reply message list, the targeted message object 52 is referred to herein as being in a "locking" state.

Preferably, an unlock request specifies the message object ID of a targeted message object 52. In the preferred embodiment, an unlock request can be issued by a server task 34, or by the message transaction unit 44 during reply operations as described above. In response to an unlock request, the locking unit 46 determines whether the message object ID is valid. If the message object ID is not valid, the locking unit 46 returns an invalid ID error to the issuer of the unlock request, and does not consider the unlock request further. If the message object ID is valid, the locking unit 46 determines whether the targeted message object 52 is currently locked. If the targeted message object 52 is not currently locked, the locking unit 46 returns a lock state error to the server task 34, and does not consider the unlock request further.

In the event that the targeted message object 52 is currently locked, the locking unit 46 determines whether another client task 32 or server task 34 is waiting to lock the targeted message object 52 by inspecting the lock wait list provided by the semaphore. If another client task 32 or server task 34 is waiting to lock the targeted message object 52, the locking unit 46 removes the corresponding client task ID or server task ID, respectively, from the top of the lock wait list, and returns control to the issuer of the lock request. In this manner, the locking unit 46 transfers "ownership" of the targeted message object's lock to the next successive client task 32 or server task 34 indicated in the semaphore without altering the list of locked message objects.

If the locking unit 46 determines that no other client task 32 or server task 34 is waiting to lock the targeted message object 52, the locking unit 46 unlocks the targeted message object 52 by removing the corresponding lock structure from the list of locked objects within the port object 54 associated with the targeted message object 52. After unlocking the targeted message object 52, the locking unit 46 returns control to the issuer of the unlock request.

Because the present invention provides for message object locking and unlocking, the value of the reference constant associated with a message object 52 can be guaranteed to remain unchanged throughout a message transaction if the message object 52 is locked at the outset of the message transaction. The use of a message object's reference constant in this manner is particularly useful when the reference constant directly references a particular memory address. In an exemplary situation, a message object's reference constant could be used to specify an address at which a file control block for a given data file is stored. Those skilled in the art will recognize that in the exemplary situation, the use of message object locking in response to a send message request ensures that a file deletion operation will not invalidate a previously pending file read operation because the address of the file control block remains valid throughout the message transaction associated with the file read operation.

Referring now to FIG. 11, a flowchart of a preferred object oriented message passing method in accordance with the present invention is shown. The preferred method passing method begins in step 100 with the object management unit 42 determining whether a port object 54 is to be created, modified, examined, or deleted in response to a corresponding server task request. If a port object 54 is to be created, modified, examined, or deleted, the object management unit 42 performs the appropriate operation indicated by the server task request in step 102. After step 102 or after step 100, the object management unit 42 determines in step 104 whether a message object 52 is to be created, modified, examined, or deleted in response to a corresponding server task request. If so, the object management unit 42 performs the action indicated by the server task request in step 106. Following step 106 or step 104, the locking unit 46 determines in step 108 whether a message object 52 is to be locked in response to a server task lock request. If so, the locking unit 46 performs the locking operations indicated in the server task request in step 110. If in step 108 the locking unit 46 determines that no message object 52 is to be locked, or after step 110, the locking unit 46 next determines in step 112 whether a message object 52 is to be unlocked in response to a server task unlock request. If so, the locking unit 46 performs the unlocking operations in response to the unlock request in step 114. If no message object unlocking is required in step 112, or following step 114, the object management unit 42 determines in step 116 whether an acceptance function is to be registered for a port object 54 in response to a server task request. If an acceptance function is to be registered, the object management unit 42 registers the acceptance function with the port object 54 specified in the server task request in step 118.

Following step 118, or after step 116 if the object management unit 42 determines that no acceptance function is to be registered, the message transaction unit 44 determines in step 120 whether a client task 32 has issued a send message request. If so, the message transaction unit 44 responds to the send message request in step 122. After step 122, or after step 120 if no send message request has been issued, the message transaction unit 44 determines in step 124 whether a server task has issued a receive message request. If a server task 34 has issued a receive message request, the message transaction unit 44 responds to the receive message request in step 126. If in step 124 the message transaction unit 44 determines that no receive message request has been issued, or after step 126, the message transaction unit 44 determines in step 128 whether a reply has been issued. If so, the message transaction unit performs reply operations in step 130. Following step 130, or following step 128 if no reply has been issued, the message transaction unit 44 determines whether a server task 34 has issued a combined receive-and-reply message request in step 132. If so, the message transaction unit 44 performs the reply operations indicated in the receive-and-reply message request in step 134, after which the message transaction unit 44 responds to the receive portion of the receive-and-reply message request in step 136. After step 136, or after step 132 if step 134 is not performed, the message transaction unit 44 determines whether operation is to terminate. If operation is to continue, the preferred method proceeds to step 100. Otherwise, the preferred method ends.

Referring now to FIGS. 12A, 12B, and 12C, a flowchart of a preferred method for responding to a send message request is shown. The preferred message passing method begins in step 200 with the message transaction unit 44 decoding the message object ID specified in the send message request. Next, in step 202, the message transaction unit 44 determines whether the message object ID is valid. If the message object ID is invalid, the message transaction unit 44 returns an invalid ID error to the client task 32 that issued the send message request in step 204, after which the preferred method ends. If the message object ID is valid, the message transaction unit 44 proceeds to step 206 and determines whether the message object 52 to which the send message request is directed is locked. If the message object 52 is locked, the message transaction unit 44 blocks the sending client task 32 until the message object 52 is unlocked in step 208. The blocking performed by the message transaction unit 44 prevents the client task 32 from performing further operations. After step 208, or after step 206 if step 208 is not performed, the message transaction unit 44 determines in step 210 whether the send message request specifies that the message object is to be locked as a result of the message transaction initiated. If so, the message transaction unit 44 issues a corresponding lock request to the locking unit 46 in step 212. After step 212, or after step 210 if step 212 is not performed, the message transaction unit 44 generates a unique message ID to correspond to the message transaction initiated by the send message request, and creates a send MCB corresponding in type to the send message request type in step 214.

Next, in step 216, the message transaction unit 44 determines whether an acceptance function specifying a message type that matches the message type in the send MCB has been registered with the port object 54. If an acceptance function has been registered, the message transaction unit 44 creates a delivery MCB 80 in the client task's address space in step 218. Preferably, the delivery MCB 80 is created in the microkernel-accessible portion of the client task's address space. Following step 218, the message transaction unit 44 passes a pointer to the delivery MCB 80 to the acceptance function in step 220. Next, the message transaction unit 44 inserts a reference to the send MCB in the pending reply message list within the port object 54 in step 222.

After step 222, the message transaction unit 44 determines whether the send MCB created is a synchronous send MCB 60 in step 250. If not, the message transaction unit 44 returns the message ID to the client task 32 that issued the send message request in step 252, after which the preferred method ends. If the send MCB is a synchronous send MCB 60, the message transaction unit 44 next prevents the sending client task 32 from performing further operations, that is, blocks the sending client task 32, in step 254. Next, in step 256, the message transaction unit 44 determines whether the maximum time interval specified in the send MCB has been exceeded. If so, the message transaction unit 44 returns a timeout status to the sending client task 32, after which the preferred method ends. If the maximum time interval has not been exceeded, the message transaction unit 44 determines whether a reply has been issued to the message indicated in the send message request in step 260. If no reply has been issued, the preferred method returns to step 256. If in step 260 the message transaction unit 44 determines that a reply has been issued, the message transaction unit 44 performs reply operations in step 262. Following step 262, the preferred method ends.

If in step 216 the message transaction unit 44 determines that a matching acceptance function is not present, the message transaction unit next determines whether a matching receive MCB is present in the port object's pending receive message list in step 224. If a matching receive MCB is not present, the message transaction unit 44 inserts a reference to the send MCB in the pending send message list in step 226, after which the preferred method proceeds to step 250. If the message transaction unit 44 determines that a matching receive MCB is present in step 224, the message transaction unit 44 creates a delivery MCB at the message buffer address specified within the matching receive MCB in step 230. Next, the message transaction unit 44 inserts a reference to the send MCB in the pending reply message list in step 232. Following step 232, the message transaction unit 44 determines in step 234 whether the receive MCB is a synchronous receive MCB 70. If so, the message transaction unit 44 unblocks the receiving server task 34 that issued the corresponding receive message request in step 240. If the message transaction unit 44 determines that the receive MCB is not a synchronous receive MCB 70, the message transaction unit 44 delivers the message referenced in the send MCB to the server task 34 identified in the asynchronous receive MCB 72 in step 236. Following step 236, the message transaction unit 44 notifies the receiving server task 34 according to the event notification information specified in the asynchronous receive MCB 72 in step 238. After step 238, or after step 240, the message transaction unit 44 deletes the receive MCB and its corresponding pending receive message list reference in step 242. Following step 242, the preferred method proceeds to step 250.

Referring now to FIGS. 13A and B, a flowchart of a preferred method for responding to a receive message request is shown. The preferred method begins in step 300 with the message transaction unit 44 decoding the port object ID specified in the receive message request. Next, the message transaction unit 44 determines whether the port object ID is valid in step 302. If the port object ID is not valid, the message transaction unit 44 returns an invalid ID error to the server task 34 that issued the receive message request in step 304, after which the preferred method ends. If the port object ID is valid, the message transaction unit 44 next determines whether a matching send MCB is present in the port object's pending send message list in step 306. If a matching send MCB is not present, the message transaction unit 44 creates a receive MCB according to the type of receive message request issued, and inserts a reference to the receive MCB in the pending receive message request list in step 308. Following step 308, the message transaction unit 44 determines whether the receive message request is synchronous in step 310. If not, the message transaction unit 44 returns the receive ID to the server task 34 that issued the asynchronous receive message request in step 311, after which preferred method ends. If the receive message request is synchronous, the message transaction unit blocks the server task 34 that issued the receive message request in step 312. Next, in step 314, the message transaction unit 44 determines whether the maximum time interval specified in the receive MCB has been exceeded. If so, the message transaction unit 44 returns a timeout status to the server task 34 in step 316, after which the preferred method ends. If the maximum time interval has not been exceeded, the message transaction unit next determines whether a matching send message request has been issued in step 318. If not, the preferred method returns to step 314. If a matching send message request has been issued, the message transaction unit 44 generates a unique message ID and creates a corresponding send MCB in step 320.

Following step 320, or following step 306 if a matching send MCB is present, the message transaction unit 44 inserts a reference to the send MCB in the port object's pending reply message list in step 330. The message transaction unit 44 then creates a delivery MCB 80 at the address specified in the receive message request or in the receive MCB in step 332. After step 332, the message transaction unit 44 determines whether the receive message request is a synchronous receive message request in step 334. If the receive message request is synchronous, the message transaction unit 44 determines whether the server task 34 that issued the receive message request is blocked in step 336. If so, the message transaction unit 44 unblocks the server task 34 in step 338. If the message transaction unit 44 determines in step 334 that the receive message request is an asynchronous receive message request rather than a synchronous receive message request in step 334, the message transaction unit 44 notifies the server task 34 that issued the asynchronous receive message request in step 340. Following step 340, or after step 338, or after step 336 if step 338 is not performed, the message transaction unit 44 delivers the message specified in the send MCB to the message buffer specified in the receive message request in step 342. After step 342, the message transaction unit 44 determines whether a receive MCB corresponding to the receive message request had been created in step 344. If so, the message transaction unit 44 deletes the receive MCB and its corresponding reference in the pending receive message list in step 346. After step 346, or after step 344 if step 346 is not performed, the preferred method ends.

Referring now to FIG. 14, a flowchart of a preferred reply method is shown. The preferred method begins in step 400 with the message transaction unit 44 decoding the message ID specified in the reply to locate the send MCB associated with the message transaction. Next, in step 402, the message transaction delivers the reply status to the client task 32 indicated in the send MCB. The message transaction unit 44 then determines in step 404 whether a reply buffer was indicated in the reply. If so, the message transaction unit 44 delivers a copy of the contents of the reply buffer to the client task 32 in step 406. After step 406, or after step 404 if no reply buffer is indicated in the reply, the message transaction unit 44 determines in step 408 whether the message object 52 indicated in the send MCB is to be unlocked upon completion of the message transaction. If so, the message transaction unit 44 issues a corresponding unlock request to the locking unit 46 in step 410. After step 410 or after step 408, the message transaction unit 44 deletes the message ID representing the message transaction in step 412. Finally, the message transaction unit 44 deletes the send MCB in step 414, after which the preferred method ends.

Referring now to FIG. 15, a flowchart of a preferred method for responding to a lock request is shown. The preferred method begins in step 500 with the locking unit 46 determining whether the message object ID specified in the lock request is valid. If the message object ID is not valid, the locking unit 46 returns an invalid ID error to the issuer of the lock request in step 502, after which the preferred method ends. If the message object ID is valid, the locking unit 46 next determines in step 504 whether the message object 52 targeted by the lock request is already locked. If not, the locking unit 46 waits for a reply to be issued for each send MCB referenced in the associated port object's pending reply message list that specifies the targeted message object 52 in step 506. Preferably, the locking unit 46 performs step 506 by first counting the number of send message control blocks referenced in the pending reply message list that specify, the targeted message object 52, after which the locking unit 46 waits for each of the references counted to be removed from the pending reply message list. After step 506, the locking unit 46 locks the targeted message object 52 by inserting a new lock structure containing the corresponding message object ID into the list of locked message objects. Next, the locking unit 46 returns control to the issuer of the lock request in step 518, after which the preferred method ends.

If the locking unit 46 determines in step 504 that the targeted message object 52 is already locked, the locking unit 46 next adds a reference to the lock request issuer to the corresponding lock structure semaphore in the list of locked message objects in step 510. Preferably, the semaphore provides a FIFO-ordered lock wait list that indicates the client task ID or the server task ID of each task that is waiting to lock the targeted message object 52. After step 510, the locking unit 46 determines in step 512 whether the issuer of the currently-considered lock request is next to receive ownership of the targeted message object's lock. In the preferred method, the locking unit 46 performs step 512 by determining whether the ID of the issuer of the currently-considered lock request is at the front of the lock wait list. If the issuer of the currently-considered lock request is not next to receive ownership of the targeted message object's lock, the preferred method remains at step 512.

Once the issuer of the currently-considered lock request is next to receive ownership of the targeted message object's lock, the locking unit 46 determines whether an unlocking request has been issued in step 514. If no unlocking request has been issued, the preferred method remains at step 514. After an unlocking request has been issued, the locking unit 46 responds to the unlock request by performing unlocking operations in step 516. Following step 516, the preferred method returns control to the issuer of the currently-considered lock request in step 518, after which the preferred method ends.

Referring now to FIG. 16, a flowchart of a preferred method for responding to an unlock request is shown. The preferred method begins in step 600 with the locking unit 46 determining whether the message object ID of the message object 52 targeted in the unlock request is valid. If the message object ID is not valid, the locking unit 46 returns an invalid ID error to the issuer of the unlocking request in step 602, after which the preferred method ends. If the message object ID is found to be valid in step 600, the locking unit 46 next determines whether the targeted message object 52 is currently locked in step 604. Preferably, the locking unit 46 determines whether the targeted message object 52 is currently locked by inspecting the associated port object's list of locked message objects. If the targeted message object 52 is not currently locked, the locking unit 46 returns a lock state error to the issuer of the unlocking request in step 606, after which the preferred method ends.

If the targeted message object 52 is currently locked, the locking unit 46 next determines whether another task is waiting to assume ownership of the targeted message object's lock in step 608. The locking unit 46 preferably performs step 608 by inspecting the semaphore associated with the targeted message object 52. If no other task is waiting to assume ownership, the locking unit 46 removes the corresponding lock structure from the corresponding port object's list of locked message objects in step 610, thereby unlocking the targeted message object 52. After step 610, the locking unit 46 returns control to the issuer of the unlock request in step 614, after which the preferred method ends. If anther task is waiting to assume ownership of the targeted message object's lock in step 608, the locking unit 46 removes the reference to the client task 32 or server task 34 at the front of the semaphore's lock wait list in step 612. Following step 612, the preferred method proceeds to step 614.

While the present invention has been described with reference to certain preferred embodiments, those skilled in the art will recognize that various modifications may be provided. For example, the message transaction unit 44 could maintain the pending send message list, the pending receive message list, or the pending reply message list without maintaining FIFO order. This and other variations upon and modifications to the preferred embodiments are provided for by the present invention, which is limited only by the following claims. ##SPC1##