Gral Kernel, Basic Functionality

Basic Functionality

Grâl is an object-oriented operating system, i.e. all components of the system are treated as abstract objects.

Unlike other operating systems, Grâl does not have processes, instead it provides an environment for unchangeable automatons to communicate with other automatons (referred to in early Grâl papers as "P-objects"). Every such automaton exists in a context, i.e. the array of accesses (i.e. references and permissions to use) to objects. Indices of accesses in a context are called local addresses. An automaton can be unprogrammable, or read its program from a memory referred to via an access found in its context.

The Grâl kernel provides a set of system calls, or a set of operations to manipulate the objects and perform synchronization between the automatons. The internal structure of automatons is implementation dependent.

In conventional computers, the automatons are merely virtual processors and memory units, with the instruction set consisting of the non-privileged instructions and system calls, and possibly featuring several concurrent threads of execution, and cache memory allowing those virtual processors to read and write large blocks of data from and to a file system.

For convenience, the term process will be used hereafter to mean an automaton together with its context. Reader should be aware that it is not the same as traditional notion of processes which also includes memory and a program stored in the memory.

Grâl kernel allows processes to create abstract objects and serve the requests to those objects initiated by other processes. User-defined objects can be used everywhere in place of intrinsic objects (i.e. objects serviced by the kernel). The process issuing requests to an object is called client, and the process performing requested actions is called server.

The access from server's context to a user object is called active access, the access from client's context is passive, meaning that client process initiates the interaction with the object, while the same object is seen as an initiator by the server.

The single act of interaction between client and server is called a transaction. Transaction types are identified by request codes, or integer numbers from 0 to 31. Every access has an associated bit mask allowing only transactions with particular request codes to be initiated using the access. A transaction as seen from the client side is called C-transaction, and S-transaction as seen from the server side.

A unique and subtle feature of Grâl is that the transactions do not carry any data, but can only be used to transport accesses between processes. Accesses being transported by a transaction are called arguments of the transaction.

The life cycle of a transaction has four distinctive stages:

The initial state (client has an access to some object A, server has access to B):

Client creates the transaction using passive access to the object, and "loads" the in-arguments of the transaction:

As a result, client is given a pointer to the transaction, as viewed from the client's side, or access to C-transaction. This access can be used by client to wait for the completion of the transaction or to cancel the transaction (the semantics of cancelation will be described later).

Creation of transaction causes an event in the server process to tell it when to start to process the request.

Server accepts the transaction, thus obtaining the pointer to the transaction from the server's side (or access to S-transaction), and unloads the in-arguments thus receiving accesses from client.

After that server may start performing the requested operations using received accesses. Accesses obtained from in-arguments of a transaction are by default temporary, i.e. can only be used until the transaction is completed; client may choose to override the default by setting one or more arguments to carry permanent accesses which will remain useful even after the transaction was completed.
Server completes the transaction by providing 32-bit integer return code (negative values indicate error condition) and "loads" the transaction with out-arguments. Out-arguments always carry permanent accesses.

Note that after completion of the transaction the temporary access held by the server is no longer useful, it expired.

Completing transaction by server causes an event in client.
When client learns that the transaction is completed it retrieves the result code and out-arguments. After that the transaction is destroyed:

An access to C-transaction can be used to cancel the transaction. The cancelation is advisory, i.e. if server already accepted the transaction it may disregard the cancelation and complete the processing. If transaction is not yet accepted it will be destroyed immediately, if transaction is already completed cancelation will have no effect.

As was mentioned before, transactions in Grâl do not transport any user data between processes. This a very important architectural feature based on the observation that if two automatons are attempting to communicate they must have the common medium and common "language", i.e. something which can be represented by a first-class object. In Grâl framework the act of communication consists only in passing the access to that object and letting the other party to know that it is wanted to communicate. The Grâl design recognizes that all interactions take some non-zero physical time, and provides means to signal the end of the interaction (that is the reason for the asymmetrical client-server scheme).

The common "language" used by a pair of processes to communicate is called protocol. The definition of a protocol needed to communicate with an object (or, to be more precise, with the object's server) includes all possible requests (identified by request codes), and protocols of corresponding in- and out-arguments. Generally, protocols form a hierarchy (i.e. lower-level protocols are used by arguments of requests of higher-level protocols), although cyclical dependencies are possible. In any case, some protocols must "shadow" the physical data pathways which actually perform the data transfer.

The protocols are represented by special entities called types. Every Grâl object has associated type. Types form inheritance trees; multiple inheritance is not supported. Unlike accesses to objects, accesses to types cannot be used to initiate transactions, or be passed to other processes. The only way to pass a type to another process is to give it an access to object of that type. The only use for a type is to check if some other object has a compatible type; i.e. if it supports the same protocol.

The reason for not allowing accesses to types to be passed to other processes the same way as accesses to regular objects is to enforce locality of type information; i.e. to make transparent type translation possible.

The most basic protocol in Grâl implementation on traditional computers is the memory protocol representing operations on arrays of bytes.

Synchronization in Grâl is based on events generated in processes on appropriate changes in the environment. Every event is associated with an access within the process' context, the cause of event corresponding the kind of access:

passive access to an object: causes event if the access has expired;
active access to an object: causes event if there's a transaction waiting to be accepted, or if there are no passive accesses to the object left;
access to C-transaction: causes event if the transaction is completed or failed;
access to S-transaction: causes event if the transaction is canceled by the client.

An event is said to cause the condition associated with it to become true. The condition will remain true until the reason for event (or the entity associated with the event) is removed. The exact semantics of events depends on the implementation of processes within particular hardware architecture.