Developing Parallel Real-Time Applications in the Hamlet Application Design Language

Developing Parallel Real-Time Applications in the Hamlet Application Design Language1Maarten V AN STEENErasmus Univ.,Dept.of Comp.Sc.(Woudenstein),POB1738,3000DR RotterdamArmand TEN DAM,Teus VOGELTNO Inst.of Appl.Physics,POB155,2600AD,Delft 1The work presented here is done within the framework of the ESPRIT program and partly funded by the Commission of the European Communities.Participants in the Ham-let project are:AEG(D),CAP Gemini(F),CASA(E),DLR(D),HITEC(GR),INESC(P),INMOS(UK), Parsytec(D),Gabriel(GR),TNO(NL),TUM(D).AbstractThe topic of how to exploit parallelism for performance enhancement has already received considerable attention.However,relatively less attention has been paid to practical development techniques for parallel real-time applications.In this paper we propose a graphical design language for supporting the technical design phase in the process of parallel real-time application development.This design language is based on a model of Communicating Sequential Processes and Data Flow Diagrams and supports exploitation of task-oriented and data parallelism.Novel features include, besides support for exploitation of parallelism for real-time applications,a strict sepa-ration of behavior and communication specification,specification of timing constraints, integration of controlflow and data transformations,and support for automated source code generation The paper also briefly pays attention to the current implementation of the language.Keywords:parallel processing,design languages,real-time systems,process replica-tion,message-passing.Contents1Introduction2 2Basic design features of ADL42.1Introduction (4)2.2Activities and communication (5)2.3Gates (7)2.3.1Gates as access points (7)2.3.2Timed communication (9)3Replication of activities113.1Introduction (11)3.2Simple replication (12)3.3Structured replication (12)3.4Discussion (13)4Designing the behavior of an application164.1Rationale (16)4.2Basic states (16)4.2.1Processing states (17)4.2.2Communication states (17)4.3Transitions (17)4.4Select states (18)4.5An example (19)5Current status and future work2011Introduction In the last decade exploiting parallelism has received considerable attention from the scientific research community.In many cases,research has focussed on exploiting parallelism for solving problems of increasing size.However,relatively less attention has been paid to the issue how parallelism can be exploited for exclusively solving problems in reduced time,as is required for real-time applications.As we see it, development of these applications differs from development of parallel scientific ap-plications in at least two ways:(1)the reason why parallelism is exploited,and(2) how it is exploited.ad.1:Reasons for exploiting parallelism.An important reason for exploiting parallelism in the case of scientific applications is due to scaling[12]:we simply want to do more in the same time.This means that the volume of data that is to be processed is enlarged,or that the time step is decreased to reduce the computational error. However,the reason for exploiting parallelism in real-time applications originates from the demand to meet harder timing constraints.Exploiting parallelism in these cases leads to more intricate models by which one can analyze the actual behavior of the application.Such an analysis is needed to determine a priori if the required timing constraints will be satisfied.This type of analysis is obsolete in the case of parallel scientific applications.ad.2:Means to exploit parallelism.Parallelism in scientific applications is gener-ally exploited by decomposition of the data space and subsequently letting a number of identical programs each manipulate a part of that data space[10].This approach differs from real-time application development.There,the application is generally decomposed into a collection of functionally distinct,concurrently behaving tasks. Exploitation of parallelism is achieved by assigning tasks to different processors.In addition,some of the tasks are subsequently replicated in order to enhance perfor-mance even further.In other words,exploiting parallelism is achieved by combining2functional(or task-oriented)parallelism,with data parallelism by replication[9].At present,there is hardly support available for developing parallel real-time applica-tions,although several methods,techniques,and languages have been developed[6]. However,these approaches hardly address the aspect of exploiting parallelism for the sake of meeting performance requirements,despite the fact that their inventors often claim otherwise.As we see it,this is caused by failing to make a distinction between parallelism as a means for,on the one hand,modeling a solution,and on the other hand, as a means for implementing it.This development cannot be continued for very long,and has also been recognized by the companies participating in the ESPRIT project Hamlet.Hamlet focuses on exploitation of parallelism for hard real-time applications.In particular,attention is paid to industrial embedded applications for transputer-based systems.The core of the project is formed by three large,time-critical applications.Based on these applications,the hardware and software requirements for development support within the project have been formulated[5].With respect to the technical design of an application,it was required to develop a graphical language based on a model of processes communicating through message-passing.The language should allow full generation of software configurationfiles for a target parallel computer.In addition, partial generation of C or OCCAM source codefiles should be supported as well.This design language is the topic of this paper.In Chapter2we introduce the basic features of the so-named Hamlet Application Design Language(or ADL for short).The language concepts and notations we propose will be explained by means of an example parallel multi-sensor system.In Chapter3 we present the way replication is supported in ADL,followed by a description of the features for modeling behavioral aspects in Chapter4.We conclude by presenting the current status and future work in Chapter5.32Basic design features of ADL2.1IntroductionThe Hamlet Application Design Language is a graphical language based on a model similar to Communicating Sequential Processes[8]and Data Flow Diagrams[17]. The main reasons for adopting these two models originate from the need to devise a method that is familiar to industrial application developers and which is suitable for distributed-memory computers.A DL is intended to be used during the technical design phase of application development.We shall explain the concepts and notations of the language by means of an example data processing system.This example is based on an ionosphere analysis system as described in[13],and a monitoring control system found in[4].We have deliberately abstracted from the actual systems in order to concentrate on the software design issues only.Example1.(Problem description)The data processing system consists of four dif-ferent sensors for measuring various environmental parameters.Sensors can either be disabled or enabled and are initially disabled.Each sensor passes its(multi-valued) parameter to an analysis component for further processing.This analysis component processes the parameters by applying some relaxation technique and produces a series of environmental vectors.Each vector is then subsequently used to calculate a pixel display value,according to a not further specified function.The display values are then passed to the console.If the analysis system detects that a sensor is generating parameter values that lie outside its limits an alarm condition is posted and the defect is reported to an operator.The status and attributes of each sensor can be set by an operator.The status of each sensor is checked every15minutes,and if a sensor does not respond within5seconds it is assumed to be defect.This will cause an alarm condition to be posted.Likewise,if the sensor does not respond to a new setting of one of its attributes,it is declared defect.In any case,if at least one sensor is malfunctioning the system shuts down completely.4defectFigure2.1:The global structure model of the monitoring system.In order to develop an application in ADL according to these system specifications,the language supports two different types of models.A structure model is used to express the structure of the application,whereas a behavioral model is used for describing the dynamics of the system.The structure model is a design expressing an application as a collection of activities that act in parallel.This task-oriented parallelism[9]may not be sufficient to achieve the required performance.Therefore,ADL also provides several replication techniques effectively leading to incorporating data parallelism in a design.Designing the structure of an application,specifying how data parallelism can be exploited,and modeling the behavior of an application are discussed in the next three subsections.2.2Activities and communicationAn ADL structure model reflects the structure of an application expressed in terms of a collection of activities that communicate by means of communication media based on a message-passing paradigm.Similar to dataflow diagrams,an activity is used to model a logical entity capable of transforming incoming data or tokens which can then be passed to another activity.Contrary to dataflow diagrams,however,we have made the means of communication more explicit by distinguishing three types of communication media:message queues,synchronous channels,and semaphores.•A DL message queues are used for modeling asynchronous,buffered communi-cation of data objects between activities.They behave according to afirst-in5first-out principle,and may have either an infinite orfinite capacity.Message queues are represented by the symbol•Synchronous channels in ADL follow the same semantics as channels or ports in most distributed programming languages[3].Contrary to message queues, communication via synchronous channels is unbuffered:sender and receiver will thus have to synchronize in order to communicate data.We use the symbol to represent synchronous channels.•Semantically,semaphores in ADL behave like message queues with an infinite capacity,with the exception that tokens instead of data are queued1.Tokens bear no additional information and are comparable to events.Receiving a value froma semaphore corresponds to Dijkstra’s P-operation,whereas sending a tokencorresponds to the V-operation.Semaphores are shown by the symbolExample2.(Global structure model)Figure2.1shows the global structure model of our data processing system2.We have distinguished four different activities,shown as large circles.Central to the design is the activity Control which is assumed to handle all communication with the operator console(modeled as the activity Console)and the actual sensors(modeled as SensorSystem).The activity AnalysisSystem represents the main computational unit which calculates the necessary display information.The communication between these activities has been modeled by means of three message queues,three synchronous channels,and two semaphores.The message queues reportQueue and command model the communication between the operator and the actual system:issuing commands and receiving various reports.The parameters as sampled by the sensors are also assumed to be appended to a message queue,named parameter.Our model further consists of three synchronous channels named respectively at-tribute,report,and pixelInfo.The synchronous channel attribute is used to communicate new values for sensor attributes.Likewise,report is used as the medium to communi-cate information by either the sensor or analysis system to the control unit whenever inappropriate functioning has been detected.The synchronous channel pixelInfo carries the actual display information that has been calculated by the analysis system.Finally,posting an alarm condition when a sensor is assumed to be defect or whenever an out-of-limit value has been detected,has been modeled by the semaphore named defect.Likewise,by using a semaphore check the control unit can indicate that SensorSystem should test the proper functioning of each of its sensors.1We note that application requirements[5]indicated that semaphores should be supported at the design level.2We note,as a matter of fact,that all ADLfigures in this paper have been constructed with the present implementation of the ADL support system.6Formally,diagrams such as shown in Figure 2.1are referred to as ADL designs .An activity in a design can be decomposed into a collection of constituent activities,yielding a so-called subdesign .An important role with respect to this hierarchical organization of activities is fulfilled by gates .In Figure 2.1gates are shown as annotations (“•”and “”)to the arcs that connect communication media to activities with the symbols.Gates are the subject of the next section.2.3GatesIn data flow diagrams,the interface of an activity is not made explicit –a situation which we feel is inappropriate when technical design issues are to be dealt with.In particular,if a technique is to support the design of parallel applications,support for communication structure design becomes apparent.In our view,an essential aspect of designing communication structures for parallel applications is localization .This means that a developer can concentrate on a relatively small part of the communication independent of other parts that constitute the overall communication structure.Similar to the approach followed in Mascot [11]we therefore propose so-called (input and output)gates .Gates in ADL serve two purposes:1.They provide a means to specify where communication with an activity takes place,i.e.they serve as explicit access points to communicate data or tokens with an activity.2.They allow for specifying when communication with an activity should com-mence from the moment that the activity is prepared for that communication.2.3.1Gates as access pointsIn their role as access points,gates can either be internal or external to a design.Gates that are internal to a design (also called internal gates),represent where activities and communication media are connected.Syntactically,internal input and ouput gates are represented as respectively small circles and boxes attached to an activity.Each internal gate is always connected to exactly one communication medium by means of an arc.Gates that are external to a design (called external gates)represent the interface of a complete collection of activities and communication media.In particular,they are used to explicitly relate an activity to its decomposition into subactivities in the following way.Suppose activity A is decomposed into subactivities ˜A1,…˜A n .Each internal gate g in attached to A is then represented by an external gate ˜gext of the subdesign in which ˜A1,…,˜A n are contained.Gates that are internal to the subdesign can,in turn,be associated with (at most one)external gate of that subdesign.Assume that gate ˜g in is an internal gate of the subdesign associated with the external gate ˜g ext .Semantically,this association implies that all communication through gate ˜g in will be subsequently7passed through gate g in of the parent activity A.To illustrate,consider the following example.Example3.(Refinement)Consider the decomposition of the activity SensorSystem as shown in Figure2.2.For each of the two internal input gates and three internal output gates attached to the parent activity SensorSystem,we have drawn a corre-sponding external(input or output)gate at the refined design.These external gates are depicted as boxes connected by dashed lines to internal gates belonging to the activity SensorControl and the four activities modeling the sensors.Each external gate has the same name as its internal counterpart in Figure2.1.Considering,for example,the internal gate parGate of Sensor1,we have that all communication which is passed through this gate will be passed via the external gate parameter to the internal gate parameter of SensorSystem shown in Figure2.1.By using internal and external gates,we need not consider the actual communication medium that is connected to the internal gate at the level of the parent activity.In fact, we need only to ensure that we have a correct one-to-one mapping between internal gates at the parent level and external gates at the child level.In other words:we need to ensure that the interfaces match.In Chapter4we shall further demonstrate the use of gates as access points when we consider behavioral models.82.3.2Timed communicationAs we have mentioned,gates are also used to specify when communication should take place from the moment an activity is willing to communicate.To this aim,gates in ADL are subject to so-called timed communication.Three types of timed communication are available in ADL:•In the case of blocked communication at a gate g,an activity which is waiting for communication via g,will not proceed until data or token transfer through g has actually taken place.•In the case of non-blocked communication at gate g,an activity will never wait until communication through g takes place,unless it can take place immediately.•Finally,delayed communication indicates that an activity is willing to wait for communication until a specified amount of time has elapsed.An input or output gate that is subject to blocked communication is represented by respectively afilled circle(“•”)or a solid box(“”).Gates that are subject to delayed communication are represented by respectively the symbol“⊕”in the case of an input gate,and by the symbol“+”in the case of an output gate.Non-blocked communication is represented by the symbols“”and“”for respectively input gates and output gates.It is important to note that these forms of communication relate to the moment when communication should take place as required by the communicator,and if this requirement could not be met communication is cancelled all together.This is different from(a)synchronous communication which involves all communicating parties,and which is,in principle,never cancelled.To further explain the semantics of timed communication,consider the communication between SensorControl and Sensor1as shown in Figure2.2via the synchronous channel status1.Example4.(Timed communication)The synchronous channel status1is used to pass the status information of Sensor1to SensorControl.What we have done is modeled the timing at the input gate statusIn of SensorControl to be subject to delayed communication.Likewise,the timing at output gate statusOut of Sensor1is subject to non-blocked communication.Anticipating our discussion on modeling the behavior of activities,we assume that Sensor1from time to time attempts to pass its status via status1.The semantics of synchronous channels are such,that communication can only succeed if there is a receiving activity at the time a sending activity wants to communicate.In our case, this means that the status can only be passed to SensorControl if the latter is indeed waiting,i.e.prepared to receive that status.Because the output gate at Sensor1is subject to non-blocked communication,the following two situations can occur:1.If SensorControl is not prepared to receive the status of Sensor1,the latterwill be immediately notified that communication fails.In this case,Sensor19will simply continue without further delay,and without passing information to SensorControl.2.On the other hand,if SensorControl is waiting to receive the status of Sensor1,communication will succeed and Sensor1will continue after having communi-cated with SensorControl.From the perspective of SensorControl the semantics of timed communication in ADL are such that the following will happen.Assume SensorControl wants to know the status of Sensor1.To this aim,it will request communication through gate statusIn.If no communication takes place within(in our case)5seconds,i.e.if Sensor1does not pass its current status within5seconds,no further attempts to communicate will be undertaken by SensorControl who must then assume that the sensor is malfunctioning. Similar semantics relate to message queues and semaphores.For example,if a P-operation is performed on a semaphore via a non-blocked(input)gate,the operation will fail in the case that no token is available.This combination of a semaphore connected to a non-blocked input gate captures the semantics of a so-called conditional semaphore[1].Likewise,if an activity wants to receive a datum from a message queue this communication will also fail if the queue is empty and communication at the associated input gate is subject to non-blocked communication.At this point we have illustrated the most important concepts and notations of an ADL structure model:activities,their hierarchical organization,and communicationmedia.By their nature,activities act in parallel and consequently,a structure model reveals the functional parallelism inherent to an application design.How one can specify data parallelism is discussed next.103Replication of activities3.1IntroductionAn important distinction between ADL and many other graphical design languages is its support for designing replicated structures.Two forms of replication are currently provided in ADL:simple replication and structured replication.In order to illustrate these two,wefirst consider a refinement of the analysis component.Example5.(Replication specification)Figure3.1shows a refinement of the activity AnalysisSystem.We have decomposed the analysis system into three activities.The activity Sampler simply collects all the parameter values sent by the sensors and applies some relaxation technique,resulting in a stream of vectors.Each vector is then used to calculate a pixel display value by the activity Compute.Finally,the activity Aggre-gateProcess aggregates the information from Compute into an appropriate stream of pixels to be displayed.The double-lined circle drawn at Compute indicates that this activity is replicated.This is the only information on replication that is shown in Figure3.1:how the activity is to replicated is considered by us as a separate design problem and which should therefore also be dealt with separately.Figure3.1:Refinement of the activity AnalysisSystem.11Figure3.2:The effect of applying simple replication of Compute.3.2Simple replicationSimple replication applied to a single activity A,yields a replacement of A by a number of copies A1,…A n.Each of these copies will communicate with its environment in the same way as A did.For example,applying simple replication to Compute yields an equivalent design as shown in Figure3.2.3.3Structured replicationThe main drawback of simple replication is that it does not permit to easily model replicated communication structures.For example,when modeling a pipeline of N activities,one would preferably want to model a single activity A,apply simple replication yielding activities A1,…,A N,and in addition specify that A i communicates with A i+1.The problem of graphically specifying such structures is related to graph grammars and has been studied for parallel systems by Bailey and Cuny[2].However, specifying regular structures remains a non-trivial exercise and requires an explicit graph rewriting language.We have therefore chosen to support replication by means of a set of predefined replication constructors,collectively referred to as structured replication.Structured replication comes in either a1-dimensional or2-dimensional form al-lowing to construct geometrical structures in which activities appear as points on a grid. The grid itself is generated by a replicator,which is formally a vector of length k in the case of k-dimensional replication.The generated grid including the communication structure between the various activities,is called the replication grid.Example6.Assume we want to replicate an activity A using the2-dimensional repli-12cator r=[n1,n2]with n i>0.This will result in2-dimensional grid with n1×n2 where0d i<n i.activities A d1,d2In order to generate regular communication structures,so-called tagged gates are used. These are special internal gates that are added to an activity that is subject to replication. In particular,when1-dimensional replication is applied,an activity will be augmented with two tagged output gates(named westOut and eastOut respectively),and two input tagged gates(called westIn and westOut).Similarly,2-dimensional replication yields yet another four tagged gates.Tagged gates are used to connect communication media that are part of the repli-cation.In addition,each such communication medium is augmented with a so-called path specification.Formally,a path specification in a k-dimensional replication is a vector of length k,that specifies the relative position in the grid of a receiving activity to that of the sending activity.Finally,the original internal gates of a replicated activity are additionally labeled with an interface label which specifies to which activity that gate will be attached after replication.To illustrate these matters,consider the following example.Example7.(1-Dimensional replication)Assume the computations on the vectors are to be processed in a pipeline fashion as mentioned above.To this aim,we specify a 1-dimensional replication as shown in Figure3.3(a).The replication design reflects that Compute is to be replicated3times(represented as“[3]”).This replication will thus yield three activities:Compute[0],Compute[1],and Compute[2].The two communication media partVector and done have been augmented with respectively the path specifications“[1]”and“[-1]”.This means,for example,that communication via done proceeds from Compute[i]to Compute[i-1].The two remaining input and output gates represent the original gates attached to Compute.They have been labeled with respectively the interface labels“[0]”and “[2]”.Consequently,the input gate of Compute will,after replication,be attached to Compute[0].Likewise,Compute[2]will have the original output gate attached to it. To conclude,Figure3.3(b)shows an equivalent representation of Figure3.3(a).The replication shown here is a so-called open replication,meaning that the activity with the highest index does not communicate with thefirst activity.In our case,this means that Compute[0]and Compute[2]do not directly exchange information.In the case of closed replication,the communication structure would simply be“wrapped”around as is the case in mesh-structures.3.4DiscussionReplication is still subject to further development in ADL.In particular,we are not yet confident that a graphical specification technique is sufficient.It may turn out13done (a)partSample[1][2]partSample[0][1]done[2][1]done[1][0](b)Figure 3.3:The specification of a pipeline of identical activities Compute (a)and an equivalent representation (b).14that a textual,or perhaps a combined form of text and graphics is more appropriate to specify replicated structures.Important,however,is that we treat the specification of replication as a separate design issue independent of the other facilities provided by ADL.We have thus provided an appropriate separation of concerns in the process of application development.In addition,we can now also incrementally incorporate specification means for other forms of replication without having to alter any basic ADL language construct.15。