System Modules

A B R O O M system involves the combination of three modules: switching elem ent, p erm anent store m anager and the node processor. T he switching elem ent conveys messages across clusters and drains node queue overflows. The storage m anager transfers pages betw een main memory and mass storage sites. The node processor has two busses, one exchanges messages betw een the node and the netw ork and the oth er transfer objects betw een internal and external memory.

T he switching elem ent is a node composed of two comm unication units back to back. Its main task is to connect two busses, decoupling the im pedance of a bus from the other. However, even in a single cluster system a switching elem ent can be used to enhance the system’s reliability. This is because it has an extra message queue that can be used to relay rejected messages.

A message is relayed by a node when its original destination is unable to receive it. The switching elem ent does not process the messages, just passes it to

another bus, so messages have a small latency in its queues. Consequently, the switching element queues are less susceptible to overflow, with more space for message relay. The queues can also be designed longer in the switching element, using the space left by the omission of functions that would be otherwise implemented in a normal node.

The storage manager is an intelligent disk controller. Its main task is to substitute or retrieve missing pages in the main node memory. When the node processor decodes a message, the object associated with it is prefetched to the node cache. If it is not in main memory, it must be fetched from the system disk. The node processor sends the unbound message to the store manager, placing it on a prefixed place in memory.

The storage manager must decode the unbound message header, associating it with the correct missing object and method in the disk. It will then replace the objects in the main memory, storing the old ones and overwriting their image in memory. The unbound message is then sent back to the node processor, using a special request procedure, and put back in the communication queue. The storage manager must have multiple ports to keep the private memory busses of the nodes insulated. It will serve the nodes in a round-robin strategy, giving a fair share of disk resource to each node.

The main module in the BROOM architecture is the node processor, which constitutes the building block for the parallel object-oriented machine. Its main tasks are: to handle messages from their creation up to their destinations; to bind messages to the associated method and object; and to execute the process activated by the bound message. The other two units (switching element and store manager) are not fully described or implemented in this work and can be emulated by a convenient host. The node processor is the central idea of the work,

the hardw are im plem entation of VOOM , and in consequence, of the message- driven object-oriented paradigm. The following sections will give a detailed description of the BRO O M node processor and its operation.

T he m ain idea behind the system modules is to apply the object-oriented m ethodology to the B RO O M system design. Every m odule in the system should be a B R O O M object, managing its own state and com m unicating with the others through a standard message passing protocol.

M ass S to r a g e N o d e P rocessor S w itch in g E lem en t

Inter-Nod© Bus System

Main M em ory

Intra-Node Bus System

Figure 4.3: B RO O M System O rganization

Figure 4.3 shows the system organization with the B R O O M node

processor as the intersection of two bus systems. The inter-node bus system

com m unicates objects that represent shared resources such as nodes, cluster

services (printer, LAN gateway, etc.) and the switching elem ent. The intra-node

bus system interconnects private node resources. Private resources interact intensively am ong themselves, requiring a m ore exclusive and high perform ance bus system. Examples are main memory, mass storage m anager and fast peripherals (video display unit, num eric co-processors, etc.). The mass storage m anager is, in reality, a shared resource, but since it interacts heavily with the memory it is initially placed in the intra-node system.

The object-oriented m ethodology implies that all modules com m unicate using the sam e message protocol in both bus systems. This would simplify system

specification and reconfiguration, bringing abstraction and standardisation to hardware design. The interface between the system and component designers is the clean object/m ethod specification. This abstracts the complexity of component or system details from each other, giving the choice of a range of implementations for both sides to use or design.

Peripherals and co-processors can be plugged in either of the busses, easily expanding the system or customising it to a particular application such as a graphical engine or an architecture emulator. The BROOM design is based in this regular approach but, due to implementation issues, the inter-node and intra-node protocols differ slightly. Moreover, there is a conventional memory interface to by­ pass the necessity of a memory controller module.