Developing transputer-based systems using HOOD and Parallel C

Infl~rmation and Software Technology 1994 36 (6) 353-360

Developing transputer-based systems using HOOD and Parallel C

Paul Moore and Peter G O'Donoghue Department of Computing Science, University of Ulster at Jordanstown, Shore Road, Newtownabbey, County Antrim BT38 OQB, Northern Ireland

Parallel C is one of a number of high level languages now being used to program the transputer as well as Occam. These languages have been used successfully to program the transputer in a variety of application areas. Large-scale software systems should be specified at higher levels of abstraction during the early stages of system development. Design methods promote a systematic and methodical approach to the development of software. This paper describes the use of a particular method, HOOD, for the design of transputer-based systems. It has been used with Ada and C to program other architectures. Both HOOD and Parallel C support concurrency and are based on the synchronous approach to inter-process communication. Therefore, a consistent approach to concurrency and communication is adopted at the design and implementation phases. The paper outlines the transformation from HOOD to Parallel C and the implementation of HOOD's design features. The overall approach is best used with coarse-grain client-server applications, though some optimization during implementation is still necessary.

Keywords: design, concurrency, communication, transputer

The transputer was first revealed in 1985, providing cost- effective parallelism and a flexible processing element for parallel architectures. There are now several processors in the transputer family, which can be grouped into the 16 bit T2xx series, the 32 bit T4xx series and the 32 bit T8xx series. Within these series, the processors can be classified by lhe amount of on-chip RAM, the number of links, details of instruction sets and the type of memory interface.

Occam ~'2 is a language supporting concurrency and synchronous communication between processes that has been developed to program the transputer. The Transputer Development System (TDS) provides a folding editor, a compiler, a linker, a configurer and other standard program development tools. Other tools have been developed for deadlock detection 3, load balancing 4, program animation 5 and debugging 6.

Extensions have been proposed to the Occam language to allow modular programming with sharing between processes 7. Formal methods s and the object-oriented approach 9 have also been applied to the use of the Occam language. The transputer has been used in a variety of application areas including real-time data acquisition l°, image processing ~L, robotics ~2, signal processing ~3 and data com- munications ~4.

However, for large-scale software projects, the use of any programming language should be preceded by the use

of a design method. HOOD (Hierarchical Object Oriented Design) ~'~6, a design method that supports concurrency and synchronous communication between processes, has been used with the Occam language 7. MOON (Modular Object Oriented Notation) ~s is a design method based on asynchronous communication that has also been transformed into Occam skeletal programs ~9. However, Inmos's enthusiasm for the Occam language has not been entirely shared by the parallel processing community. In recent years, the programming of the transputer has seen a migration away from Occam to higher level languages 2°.

Parallel C is a language developed by 3L Ltd that is a useful alternative to Occam which is preferred by many software engineers for implementing transputer-based systems. This paper describes the transformation from a ItOOD design to a Parallel C skeletal program. The elements of the HOOD design to be transformed into Parallel C are the object hierarchy, the use relationships, operations and execution request constraints. There are significant differences between Parallel C and Occam which have necessitated different transformation mechanisms from HOOD. The major differences include the program structures, as Parallel C uses a different source file for each parallel process. Furthermore, Parallel C does not support a process hierarchy as Occam does.

The basic objects of the design tree are called terminal

0950-5849/94/060353 08 ~ 1994 Butterworth-Heinemann Ltd 353

Developing transputer-based systems using HOOD and Parallel C: P Moore and P G O'Donoghue

objects. HOOD also classifies objects as active or passive. A passive object simply provides its operations for sequential execution by external objects. An active object has behaviour of its own and controls access to its operations which may be provided in modes other than sequential.

This paper commences with brief descriptions of the HOOD design method and the Parallel C language. Details of the transformation of passive terminal objects describe the different implementations of objects enforcing exclusive access and objects allowing simultaneous access. The implementation of HOOD's execution request constraints for the operations of active objects are outlined. The implementation of non-terminal objects, the object hierarchy, classes and arrays is also described.

HOOD

HOOD is an object-based method that supports concurrency and hierarchical decomposition. It is a merged method based on abstract machines and object oriented design zl. The method addresses real-time issues such as time-outs and exception handling. The hierarchical decomposition of the HOOD method takes the form of a parent-child hierarchy where objects can be decomposed into lower level objects as shown in Figure 1. A system is first represented as a single object within its context, specifying the external systems it interacts with. The system is gradually decomposed into an object hierarchy until all the terminal objects of the hierarchy have been identified. HOOD supports encapsulation as objects provide some operations through a provided interface but hide other operations. There are two different types of object, active objects and passive objects, which are represented by slightly different symbols.

The objects, 'parent ' , 'active' and 'obj ' are active objects whereas 'passive' is an example of a passive object. A passive object has no control of its own and simply provides operations to client objects to use sequentially. Active objects, on the other hand, are associated with states and behaviour which are described by their object control structure (OBCS). Another difference is that the operations provided by active objects can be assessed in modes other than sequential.

As well as the parent-child hierarchy, there is a seniority hierarchy which specifies client-server relationships called 'use' relationships between objects. In Figure 1, the line between the objects 'active' and 'passive' is a 'use'

] parent

/ ( i o jL0 N ]l:C,as . I II ronues4 onse

Figure 1 A HOOD diagram

relationship where 'active' is the senior object using the facilities provided by 'passive' which is the junior object. Figure 1 also shows that 'use' relationships can be anno- tated with dataflow symbols. Objects can be instantiated from classes so that the specification of equivalent object structures are not duplicated. HOOD diagrams are kept even more concise by allowing arrays of objects, such as 'obj ' to be instantiated from classes.

There are four execution request constraints that can be associated with the operations of active objects:

HSER (Highly Synchronous Execution Request) LSER (Loosely Synchronous Execution Request) ASER (Asynchronous Execution Request) TOER (Timed Out Execution Request)

The timed-out execution request constraint is used in conjunction with the other three. The use of an operation of an active object not only depends on the execution request constraint associated with the operation but also on the current state of the object.

A virtual node is an object that represents a subsystem to be placed on a particular processor, allowing hardware constraints of systems to be specified. HOOD augments its diagrammatic notation with text descriptions of objects and operations. HOOD is mainly used with the Ada language 22 but transformations to ELECTRE 23, ESTEREL 24 and Occam 19 have also been developed.

The remainder of this paper discusses the use of Parallel C and transformation of HOOD designs into Parallel C implementations. To evaluate the approach, experience of its use for an example application is reported. The types of system for which the approach is best suited are identified. The benefits as well as some limitations of using HOOD with Parallel C are also considered.

Parallel C

Parallel C is an effective alternative to Occam for programming the transputer. It is based on Kernighan and Ritchie C 25, rather than ANSI C, but has been extended to include many of the key ANSI C features. Parallel C is based on the same process model of computing as the transputer and has been used for a variety of transputer- based systems developed from a PC/Unix host.

A Parallel C program is a collection of active sequential programs, called tasks, that execute concurrently, communicating with each other through channels. As in CSP 26 and Occam, a channel connects two processes and can only pass messages in one direction; from the sending process to the receiving process. The program is a static structure and new channels cannot be created at run time.

The transputer has four bi-directional links and arbitrary networks of transputers can be constructed. The tasks that are assigned to transputers of such a network can be considered as 'black box' processes. Tasks do not share data and the only communication between them is achieved by message passing. This allows for substitution and the system recompiled without the rest of the tasks being affected. Within tasks, threads can be created. Threads within tasks share the processing time of the transputer the task is placed on. Therefore, threads are considered as

354 Information and Software Technology 1994 Volume 36 Number 6


co-routines rather than parallel processes. Unlike tasks, threads can access common data within the task and semaphores are used to control the access to such shared data.

The allocation of tasks to transputers is specified in the configuration file of an application. This file contains four main sections:

(1) The definition of the hardware configuration (processors and links).

(2) A list of tasks. (3) Specification of communication channels and the tasks

they connect. (4) Details of task placement,

Transformation of passive terminal objects

Consider the passive terminal object shown in Figure 2. It provides two sequential operations to N senior external objects. A passive object has no control of its own. It simply serves requests tot the operations it provides. Although the passive object does not have an OBCS in HOOD, it is necessary for the communication between it and any external objects to be implemented in Parallel C.

The HOOD object is transformed into a Parallel C task, an example of which follows. The main function of the task is the OBCS for an active object. In the case of a passive object, the main function of the corresponding task im- plements the object's communication with other objects in a way that represents the passive nature of the object. Each operation of an object is transformed into a function that represents its algorithmic detail. This is derived from the operation control structure (OPCS) within the HOOD design. The representation of the use relationships as an array of input channels and an array of output channels allows concise tasks to be generated.

l* PassiveObj */

# include <chan.h> #include <alt.h >

# define oplRequest 1 # define op2Request 2

# define DONE 0

main(argc, argv, envp, inpor ts , ins, out_ports,outs) int argc, ins, outs; char *argv[], *envp[]; CHAN *in ports[], *out ports[I;

/* in ports[i] is from P(i) *[ /* out_ports[ i ] is to P(i) etc */

int i, request; for (;;) { ?* continuously monitoring for requests */

i = alt wait_vec(ins, in_ports); chart in word(&request, in ports[i]);

Figure 2

/ P N - 1

A passive terminal object

switch (request) { c a s e opl Request:

opl (in_ports [i ] ,ou tpor ts [i]);break; c a s e op2Request:

op2 (in_ports [i] ,out_ports [i]);break; }

}

opl (FromChan,ToChan) CHAN *FromChan, *ToChan; {

/* implementation of opl OPCS */ chan out_word (DONE, ToChan);

} op2 (FromChan,ToChan) CHAN *FromChan, *ToChan; {

/* implementation of op20PCS */ chan_out word(DONE, ToChan);

}

Though senior objects using a passive object access it sequentially, there are a number of different ways the passive object can provide its operations to the senior objects without effecting their view of the passive object. The previous implementation enforced exclusive access to the passive object. Where simultaneous access to 'read-only' operations is allowed, each senior object is served by a different thread within the task that represents the passive object. If both 'reading' and 'writing' operations are provided, semaphores are used to control the access to shared resources. If a particular senior object has a higher priority than the others, the thread that represents the service of the high priority senior object is given a ' T H R E A D URGENT' priority.

Transformation of active objects

Consider the active object shown in Figure 3 which provides five constrained operations including ASERop which is provided asynchronously. To allow a senior using object to request ASERop and immediately continue with its following action, a mechanism is needed to capture such requests immediately, even if the required operation is not immediately available. The method used to achieve this is the provision of a high priority request handling process that executes in parallel with the process representing the operations of the active object. The structure of the task representing the active object is shown in Figure 4.

In Parallel C, the request handler is established as a thread with a higher priority than the operations thread.

IISER LSER ASER

TOER delayl by HSER~z..4 ~ TOER delay2 by LSER---7~

Figure 3 An active object

~ k /PN- I

(I c"veOUi / 1 HSERop LSERop ASERop TOERbyttSERop TOERbyLSERop \

blfi~rmation and Software Technology 1994 Volume 36 Number 6 355


Response PN-I

ActiveObj

Figure 4 Process structure of an active object implementation

# define WORKSPACE_SIZE 1024 char*ws; CHAN *Send, *Response;

main(argc, argv, envp, in_ports,ins, out_ports,outs) int argc, ins, outs; char *argv[ ], *envp [] ; CHAN *in_ports [ ], *out_ports [ ]; {

ws = maIIoc(WORKSPACE SIZE); thread_start(request~handler,ws,WORKSPACE_SIZE,

THREAD_URGENT, 4, in ports,out__ports, Send,Response);

thread_create(operators,WORKSPACE_SIZE,2, Send,Response);

}

The request handler process is listed in the Appendix. The use of the 'alt.__wait__vec' facility, rather than repeated use of the 'alt__nowait__vec' facility, prevents any processor time being consumed before any input channel becomes ready to communicate. However, where response to a request for an asynchronous operation is not so critical, the request handler thread does not require a high priority. A further alternative is to implement the request handler and the operations process as separate tasks. This is necessary to reduce the execution time of the operations provided where the volume of requests is high, increasing the ratio of communication to computation.

Figure 5 shows the sequence of message passing involved between a senior object, the request handler and the operations thread for the three operations that do not involve time-outs.

When a highly synchronous operation has a time-out associated with it, there are three alternatives. The first is normal execution of the operation which completes before it is timed out. The other two alternatives are that the operation is timed out before it finishes or that it is timed

Senior Object Requests Operations

HSER

PreCall ~, HSERopReq ~- start

PostCall ¢ done • done

i BUSY I~HSERop

LSER

PreCall ~ LSERopReq start BUSY

I~ LSERop acknowledge PostCall ~ done

ASER

PreCall ~ ASERopReq ~ start BUSY

I~ ASERop PostCall ~ done

Figure 5 Execution events for operation access without time-outs

out before it starts. There are only two possible sequences for the loosely synchronous operation that has a time-out associated with it. It either executes normally or does not start because it has been timed out before the senior user received an acknowledge message.

The request handler maintains a queue of requests. The information associated with each request includes details of the senior user making the request, the operation being requested and the time at which the request was made. The skeletal algorithm for the request handler is listed below and fully developed in the Appendix.

/* initialize FIFO request queue */ for(;;){

/* Operation not currently being executed */ for ( ; / * request not started */ ;){

i f(/* FIFO request queue is not empty */){ /* start request on front of queue */ /* unless it has been timed out */

}else{ /* wait for request for operation to arrive */ /* and start the operation immediately */

} } /* Operation being executed */ /* any further requests to join FIFO request queue */ for(;/* operation not yet completed */ ;){

i f(/* a further operation request arrives now */){ /* store request at back of FIFO request queue */

} }

}

Transformation of non-terminal objects

Consider the non-terminal object shown in Figure 6. Because Parallel C does not support process hierarchies, the non-terminal object is represented as a network of tasks as shown in Figure 7. There is a task for each child object as well as the PROVIDED INTERFACE (prey) and the REQUIRED INTERFACE (reqd).

The tasks (and the interconnections between them) that make up a Parallel C program are specified in the configuration file.

P0 PN-I

I-- PassiveNonTerminal

Figure 6 A non-terminal object

Figure 7 Task network representing a non-terminal object


Developing transputer-based systems using HOOD and Parallel C: P Moore and P G 0 'Donoghue

PROCESSORS

task Po ins = 2 outs = 2 data = 10K

task PN-1 ins = 2 Outs = 2 data = 10K

taskprov i n s = N + 2 o u t s = N + 2 d a t a = 1 0 K task a i ns=2 o u t s = 2 data= 10K task b ins = 2 outs = 2 data = 10K task c ins = 2 outs = 2 data = 10K task reqd i ns=4 o u t s = 4 d a t a = 1 0 K

! INTER-TASK COMMUNICATION

connect Po[1] prov[0] connect prov[O] po[1]

connect PN-I [1] p r o v [ N - 1 ] connect p r o v [ N - 1 ] PN-I [1 ]

connect prov[N] a [0 ] connect a [0 ] prov[N] connect p r o v [ N + l ] b [0 ] connect b [0 ] prov[N + 1] connect b [1 ] c [0 ] connect c [0 ] b i l l connect a l l ] reqd[0 ] connect reqd[01 a [1 ] connect c [1 ] reqd[1] connect reqd[1 I c [1 ] connect reqd[2 ] r l [ 0 ] connect r l [ 0 ] reqd[2 ] connect reqd [3 ] r2 [0 ] connect r2 [0] reqd [3]

PLACEMENT DETAILS

Transformation of the parent-child hierarchy Although Parallel C represents a program as a fiat network of tasks, information about the hierarchical structure of the HOOD design can be expressed as comments within the configuration file. Consider the HOOD hierarchy in Figure 8 Figure 9 shows the network of tasks that form the Parallel C implementation of this design, Each object that provides operations to senior objects has a task for its pro- v ided interface. Each object that requires operations from junior objects has a task for its required interface. Each terminal object needs a single task to represent its internal detail, whereas a non-terminal object must be transformed into tasks for each of its child objects. Within the comments, indentation is used to reflect the hierarchical structure of the design.

Figure 9 also shows the ports each task uses for communication. Each use relationship is a hi-directional communication relationship that is represented by two ports, in__ports[i] and o u L p o r t s [ i ] , where i is the positive integer the task associates with the use relationship.

The configuration file lists the tasks and connections between the tasks on the left. Comments to the right of the

r[ o~i0

U ~1o~

7__,,bi~ --)

( [ o~.i12

\

Figure 8 An example parent-child hierarchy

J

obj0

(

Figure 9 Task network for an example parent-child hierarchy

configuration file describe the parent-child hierarchy of the HOOD design.

I

! PARENT CHILD HIERARCHY

task obj0pr ins = 2 outs = 2 data = 10K

taskobjlpr ins=2outs=2data=10K task objl l ins=2 outs=2 data= 10K

task objl2pr ins=2 outs=2 data= 10K taskobj121 ins=2outs=2data=10K taskobj122 ins=l outs=l data=10K taskobjlrq ins=2outs=2data=10K task obj2 ins=l outs=l data=10K

objO PROV INTERFACE objl

PROV INTERFACE obll 1 objl2

PROV INTERFACE objl 21 obj 122 REQD INTERFACE

obj2

h!,Cormation and Software Technology 1994 Volume 36 Number 6 357


Classes and arrays

In HOOD, objects can be instantiated from a single class, which prevents duplication of the specification of their common object structure. If several objects are instantiated from a single class, then only one source file is needed to implement each of the objects. However, there must be an executable task for each object. Therefore, a HOOD class definition is transformed into a single source file which is then compiled into an executable task for each object instantiated from the class. In HOOD it is also possible to instantiate an array of objects from a class. 0nly one source file is needed to represent the class. This source file is compiled into an executable task for each component of the array of objects.

Virtual nodes

A virtual node is a HOOD object used to represent a subsystem to be placed on a particular processor. When HOOD is used with Parallel C, the virtual node represents an object to be placed on a particular transputer. The use relationships between the virtual node and other virtual nodes (both senior and junior) are represented by hard channels. The total number of hard channels that can be used to communicate with the virtual node is restricted to four, which may result in the need for multiplexer tasks to be included in the implementation. Where a number of objects are to be executed on a particular transputer, they should be designed as children of the virtual node for that transputer.

Evaluation

For the purposes of evaluation, a systolic matrix multiplication example was developed using the approach outlined in this paper. The systolic matrix multiplication application is a fine-grain example involving a two-dimensional array of processes. Although arrays of objects are allowed in HOOD, Parallel C does not provide a mechanism to define a corresponding array in the configuration file. This is in contrast to the Occam language which supports replicated PARallel processes and arrays of channels. In this particular case study, the initial design, which used an array of objects, was transformed into one that did not use arrays, as shown in Figure 10. Each object was implemented by a task and each use relationship was implemented by a pair of channels. Therefore, each task had the same number of input ports as output ports and the same subscript was used for both channels of a use relationship. The port subscripts used by each object for each use relationship are marked on Figure 10.

An object's calls of the operations of more junior objects were specified informally during the design phase. The algorithmic detail of the OBCS of each object and the OPCS of each operation was entered during implementation. The HOOD design was transformed into a Parallel C skeletal program, strictly following the guidelines outlined in this paper. Before implementation continued, it was necessary to make some modifications to this skeletal program.

Any passive object that provided a single operation did not require a switch statement, within its OBCS, to inspect

mt

. ._ . /

\ /

Figure 10 The systolic processes expressed without arrays

the operation request. Furthermore, any use relationship that only involved asynchronous operations could be implemented by a single channel as communication was uni- directional. It was also decided that it was not necessary to define a function for each operation as some of them were trivial and could be implemented within the OBCS.

The case study also illustrated the importance of con- sidering the hardware configuration during the design phase. The application was implemented on one-, two- and four-transputer configurations. Once the logical objects were placed on virtual nodes, representing transputers, it was necessary to introduce multiplexer objects as each bi- directional link could only be used for one pair of channels. This is not the case with processors such as the IMS T9000 which supports multiple channels over each physical link.

Once the skeletal program had been optimized, implementation was straightforward and each object could be compiled from the source file representing its class. Some of the difficulties experienced during the development of the system arose as a result of imposing client-server relationships between objects where no such relationships existed in the conceptual nature of the application. This case study used a simple example that would have required less effort if simply developing using Parallel C without a design notation. The use of a design method is recommended for large-scale software projects, especially if they are to be undertaken by a team of software engineers who must achieve a conunon understanding of the system. However, this case study has also demonstrated that the approach is suitable for certain types of system. Coarse-grain systems can be developed in HOOD and transformed into Parallel C



without as much optimization as fine-grain systems with many simple operations. Systems where client-server relationships can be introduced naturally, especially those using processor farm techniques, would benefit from the approach.

Conclusions

Transputers are now being used within large-scale real-time and embedded systems. However, the design of such systems is often informal and based on methods that have no direct support for concurrency. Large-scale software projects are best undertaken using high level design nota- tions before introducing algorithmic detail with a programming language. HOOD is a design method, supporting concurrency and synchronous communication, that has been used to design transputer-based software to be implemented in Occam. In recent years, transputer-based systems have seen a gradual migration from the use of Occam to the use of higher level languages such as Parallel C that provide stronger data types.

This paper has outlined how HOOD can be used to develop transputer-based software to be implemented in Parallel C and reported on experiences of using the approach. The general approach, which is suitable for coarse-grain client-server applications, can also be used with other high level languages to develop transputer-based software. Par.c is an alternative version of C developed by Parsys Ltd that provides parallelism by extending the syntax of C rather than using libraries of communication, alternation and semaphore primitives. Ada and parallel versions of FORTRAN have also been used to program the transputer and could be used as implementation alternatives for systems designed using HOOD. Ada, in particular, has been used with HOOD to program non-transputer architectures for real-time and embedded systems.

References

1 lnmos, Occam2 Reference Manual Prentice-Hall (1988) 2 Jones G and Goldsmith, M Programming in Occam2 Prentice-Hall

(1988) Vishnubhotla, P 'Deadlock-free programming on transputer networks' Proc. 3rd Conf North American Tran~wuter Users Group (April 1990) pp 163-174 Tambwecar, S, Shukla, U S and Paulraj, A 'LIBRA: a load balancing tool for a reconfigurab[e parallel computer ~ Proc. 13th Occam Users Group Technical Meeting (September 1990) pp 95-107

5 Vornberger, O and Zeppenfeld, K 'Graphical visualization of distributed algorithms" Proc. 3rd Conf North American Transputer Users Group (April 1990) pp 223-234

6 Dirkx, E 'IMISSED-T: Interactive microprocessor instruction set simulation environment with graphical display for transputers' Proc. 1st Conf. North American Transputer Users Group Utah (April 19891 pp 143-150

7 Barrett, G "The development of Occam: types, classes and sharing' Proc. 13th Occam Users Group Technical Meeting (September 1990) pp 119-147

8 Roantree, D and Clint, M "A formal top-down development method for Occam programs' Proc. 13th Occam Users Group Technical Meeting (September 1990) pp 262-286

9 Zhang, R, Fernandez, E B and Wu, J "A parallel implementation of robot control equations' Proc. 4th Conf North American Transputer Users Group (October 1990) pp 131 - 142

10 Duncan, B V, Powers. L S and Stiles, G S 'TransAcq: real time data acquisition and analysis system for optical spectroscopy' Proc. 3rd Conf North American Transputer Users Group (April 1990) pp 1-6

l l Henderson, T B, Synianski, J J and Bromley, K 'Software development on the video analysis transputer array' Proc. 1st Cot!f North American Transputer Users Group Utah (April 1989) pp 88-98

[2 Whitcombe, L L and Koditschek, D 'Transpnters at work: real-time distributed robot control' Proc. 4th Conf North American Transputer Users Group (October 1990) pp 107-118

13 Guisewite, G M 'Transputer performance in digital signal processing applications' Proc. 4th Conf. North American Transputer Users Group (October 1990) pp 226-234

14 May, D and Shepherd, R 'The transputer implementation of Occam' in Fleming, P 1 (ed) Parallel processing and control lEE Control Engineering Sequence 38, Peter Peregrinus Ltd (1988) pp 85-98

15 Robinson, P J HOOD Prentice-Hall ll992) 16 HOOD W,,~rking Group 'HOOD Reference Manual' draft B issue 3.0

(June 1989) 17 Hull, M E C and O'Donoghue, P G 'HOOD design for transputer-

based systems" Proc. 5th Int. Cor~ S~[~. Eng. and its Applications, Toulouse (December 1992)

18 Hull, M E C, O'Donoghue, P G and Hagan, B J 'MOON: Modular object oriented notation' Soft. Eng. J. Vol 6 No 1 (~anuary 1991) pp 25-33

19 Hull. M E C, O'Donoghue, P G and Curran, P 'Embedded system specification and transformation into Occam' J. Microcomputer Application,s Vol 16 (September 1993) pp 347 367

20 Trew. A and Wilson. G Past, present, parallel: a survey ~f available parallel computing ©'stems Springer-Verlag (1991) p 22

21 Booth, G "Object oriented development' IEEE Trans. Soft. Eng. Vol SE 12 (February 1986)

22 Bertrand, L and Heitz, M 'Hierarchical Object-Orientated Design and Ada' Proc. Ada - Europe Conf. Munich, Ada C,mlpanion Series, Cambridge University Press (1987)

23 Legout, C 'ELECTRE, a target language lot the HOOD method for the CONCERTO development environment" Proc. 5th Int. Conf Soft. Eng. and its Applications (December 1992)

24 Heitz, M and Sneed, I 'HOOD-ESTEREL methodology tk~r formal design and development of real-time systems' ESF-FERESA sub- project, document ESF/MHIS5/89 (November 1989)

25 Kernighan, B W and Ritchie, D M The C programming language Prentice-Hall (1978)

26 Hoare. C A R Communicating Sequential Proce.~ses Prentice-Hall (1985)

Appendix: Implementation of request handler for active objects # include <t imer.h >

# define DONE # define HSERopRequest # define LSERopRequest # define ASERopRequest # define TOERbyHSERopRequest # define TOERbyLSERopRequest # define ACKNOWLEDGE

# define QSIZE 100

typedef struct t int ID, OP, TIME;

i RequestRecord;

request_handler(in ports,out_ports, ToOps, FromOps) CHAN * i n p o r t s , *out__ports; CHAN *ToOps, *FromOps;

RequestRecord Queue[QSIZE] , ThisReq; int Front,Back,Length; int request, response; int Now, i; int / * Boolean */OpBusy;

/* initialize FIFO request queue */ front = 0; back = 0; length = 0; OpBusy = FALSE; for(;;){ /* continuous */

lnfi~rrnation and Software Technology 1994 Volume 36 Number 6 359


/* Operation not currently being executed */ for (; !OpBusy ;){

if( Length > 0 ){ /* start request on front of queue */ /* unless it has been timed out */ Now = timer__nowO; Th isReq=Queue[Front ] ; / * whole record ! */ Front = (Front + 1)% QSIZE; Length = 1 ; switch (ThisReq.OP) {

case HSERopRequest : chan out_word(ThisReq.OP, ToOps); OpBusy = TRUE; break;

case LSERopRequest : chan_out_word(ThisReq.OP, ToOps); chan out word(ACKNOWLEDGE,

out_ports [ThisReq.ID]); OpBusy = TRUE; break;

case ASERopRequest : chan_out_word(ThisReq.OP, ToOps); OpBusy = TRUE; break;

case TOERbyHSERopRequest : if(Now-ThisReq.TIME < delay 1){

chan_out__word(ThisReq.OP, ToOps); OpBusy = TRUE;

}else{ /* Timed Out */

} break;

case TOERbyLSERopRequest : if(Now-ThisReq.TIME < delay2){

chan_out_word(ThisReq.OP, ToOps); chan__out_word(ACKNOWLEDG E,

out_ports [ThisReq.ID]); OpBusy = TRUE;


} break;

} }else{

/* wait for request for operation to arrive */ /* and start the operation immediately */ i = alt__wait_~vec(N, in_ports); chan_in_word(&request, in_ports [i]); ThisReq.TIME = timer__now(); ThisReq.OP = request; ThisReq.ID = i OpBusy = TRUE; chan_ouL_word(ThisReq,OP, ToOps); if((ThisReq.Op = = LSERopRequest)[I

(ThisReq.OP = = TOERbyLSERopRequest)){ chan_out__word(ACKNOWLEDG E ,out__ports

[ThisReq.ID]); }

} } /* Operation being executed */ /* any further requests to join FIFO request queue */ for(; alt_nowait(1, FromOps)= = 0 ;){

if((i = al t~nowait_vec(N, in_ports))> = 0 ) { /* store request at back of FIFO request queue */ chan_in_word/&request, i n p o r t s [i]); Now = t imer~now0; Back = (Back + 1)% QSIZE; Length + = 1 ; Queue [ Back ] .OP = request; Queue [ Back].lD = i; Queue [ Back] .TIME = Now;

} } /* operation completed */ Now = timer__now0; OpBusy = FALSE; if(ThisReq.OP = = HSERopRequest){

chan_out~word(DONE, out~_ports [ThisReq.ID]); }else if(ThisReq.OP = = TOERbyHSERopRequest){

if(Now-ThisReq.TIME < = delay1){ chan out__word(DONE, out__ports [ThisReq.ID]);


} }


Developing transputer-based systems using HOOD and Parallel C

Documents

Transcript of Developing transputer-based systems using HOOD and Parallel C