2.1 The UC++ Abstract Machine Model
The UC++ abstract machine provides a target system independent way of describing and reasoning about the behaviour of UC++ programs.
The mapping of active objects to real processors depends on the process allocation mechanism of the operating system on the target system. By default, each request to create an active object will be satisfied by asking the operating system to create a new active objects process, if possible on a new processor (but taking into account any locations of active objects specified in a UC++ program).
A processor can only access memory within its local address space. Any attempt to use an address where Processor_addr is not the address of the local processor will cause an error. This memory structure means that an active object can only access its own local memory and no other.
The physical representation of an address is dependent on the runtime system provided for a particular target architecture.
The actual communication medium is dependent on what is provided by the selected target system.
1. sequential machines such as a single UNIX workstation,
2. multiprocessor computers with shared memory,
3. multiprocessor computers with distributed memories, and
4. distributed computers systems, connected by a suitable network.
By providing a suitable runtime library, UC++ programs can be supported on any of the architectures. To be executed on a different architecture, a UC++ program only needs to be recompiled in order to generate object code using the correct instruction set and to link the appropriate runtime libraries. No source code needs be changed.
Indeed, UC++ goes further than this and supports the execution of applications on a hetergeneous mixture of any of the architectures supported..
A remote function call may be made asynchronously to an active object, so the caller does not wait for a result. An asynchronous call is the mechanism by which parallel behaviour is started.
Pass by copy differs from normal C++ parameter passing in two ways:
1. The parameters are serialised i.e. transformed into a stream of printable characters by the UC++ runtime library and formed into a message. This message is transmitted to the target process and the parameters deserialised before the target function is called.
2. Reference and pointer parameters within a called function refer to copies in the address space of the target active object, hence any modification of this data will have no effect on the data visible to the caller.
Pass by copy performs serialisation by means of the input and output operators '>>' and '<<' defined in the streams library. The streams library defines suitable functions for primitive data types only. The application developer is expected to provide appropriate functions to serialise application specific data types.
When the application's main function returns, the runtime system will terminate any remaining active objects. It is preferable to avoid this action, as termination will occur in an arbitrary order without regard to any dependencies between active objects.
Generated with CERN WebMaker
2.1.1 Virtual Processors
The UC++ active object model is based on an abstract machine consisting of a networked collection of virtual processing elements (i.e. processor/memory pairs), each supporting an active object. The model assumes that each virtual processor supports only a single active object and that the object has only a single thread of control.2.1.2 Global Address Space
The abstract machine defines a global address space, where each address has a two part representation of the form: Processor_addr.Local_addr. Processor_addr identifies a particular processor. Local_addr is an address within the local address space defined by the memory directly available to the processor. 2.1.3 Virtual Processor Communications
All virtual processors are connected to a common communication subsystem. Packets of data may be passed between any two processors. Communication between active objects is built on top of this basic mechanism. 
2.2 Active Object Programming Model
This section outlines the UC++ active object model in the form seen by the programmer. A UC++ application consists of a number of active objects each supported by a single process. Active objects communicate by means of messages, which are produced, transmitted and processed by the UC++ runtime library.2.2.1 Pointers
All pointers in a UC++ program appear and behave in the same way as in C++, except for the following:
Apart from these restrictions, pointers to active objects and pointers to any other values are not distinguished and standard C++ pointer syntax and semantics apply.2.2.2 Remote Function Calls
Remote function calls, that is member function calls from one active object to another (or from a non-local passive object) are treated as messages between the virtual processors. Each processor maintains a queue which is processed in order by the active object. Once running a member function must complete and terminate before the next message in the queue will be processed.2.2.3 Parameter Copying
When an active object member function is invoked, the caller and called object do not share a common address space, do not need to reside on the same system and may not even be executing in the same hardware architecture. For these reasons, a modified form of parameter passing is used, called pass by copy.2.2.4 Application Termination
Active objects are normally terminated as a result of the delete operator. The implicit destructor is executed synchronously, which gives a guarantee on return, that all processing by the target object is complete.
UC++ - 02 MAY 95
[Contents] [Top] [Next] [Previous]