N.Gehani, K.Ramamrithan, \Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems," Journal of Real Time Systems, No.3, 1991.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....of stack space. In view of these problems most designers of realtime programming languages decide to forbid recur sion in their languages, e.g. RT Euclid (cf. 6, 5] Supported by the Austrian Science Foundation (FWF) un der grant P10188 MAT. PEARL (cf. 3] Real Time Concurrent C (cf. [4]) and the MARS approach (cf. 7, 11] Our approach is different in that we do not forbid recursion, but instead constrain recursive procedures such that their space and time behavior either can be determined at compile time and or can be checked at runtime. Thus timing errors can be found ....

N. Gehani and K. Ramamritham. Real-time Con- current C: A language for programming dynamic real-time systems. The Journal of Real-Time Systems,

....not have the expressive power of regular expressions. The reported examples (cf. 7] show that tight bounds can be derived using this method. On the other hand, the user must specify upper bounds for general loop statements. Determining the execution time of a code segment is also mentioned in [10]. Real time concurrent C uses a tool which originally is based on [11] The code can have loops with user specified loop bounds. Summing up, most researchers try to ease the task of estimating the number of general loop iterations by forbidding general loops, i.e. by forcing the user to supply ....

....Assume that the only thing that is known is U 6 I, an upper bound for the number of iterations of a general loop. Then we define the remainder function of a discrete loop by ri U, r. l r. 1. Obviously this is semantically equivalent to the approaches described in the introduction (cf. [2, 5, 7, 8, 10]) If the upper bound U is exceeded, the exception loop error is raised, which must be caught by an appropriate exception handler in order to treat this exceptional case. 2) An upper bound for the amount of time T the loop uses can be given by ri T, 8.1) r = r time(loop body) where ....

N. Gehani and K. Ramamritham. Real-time Concurrent C: A language for programming dynamic real-time systems. The Journal of Real-Time Systems, 3:377-405, 1991.

....languages, and specification languages (or formalisms) that are used to describe timing constraints at the application level, or even at the system level. Examples of application programming languages are Tomal [KH76] Pearl [Mar78] Real Time Euclid [KS86] RTC [ITM92] RealTime Concurrent C [GR91], Dicon [LG85] Chaos [BG92] Flex [LN88] TCEL [GH93] Ada95 [ANS95] MPL [NTA90] and CaRT Spec [WSM95] These languages include a wide variety of features that allow the compiler (and possibly the run time system) to check assertions or even to transform code to ensure adherence to timing ....

N. Gehani and K. Ramamritham, Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems, Journal of Real-Time Systems, 3(4):377--405, December 1991.

....expressions. Since processing this information sometimes requires exponential time, an interface definition language is introduced which allows e#cient analysis but does not have the expressive power of regular expressions. 4. Determining the execution time of a code segment is also mentioned in [GR91] Real time concurrent C uses a tool which originally is based on [MACT89] 5. In [PK89] language constructs have been introduced in order to let the programmer integrate knowledge about the actual behavior of algorithms which cannot be expressed using standard programming language features. ....

....they cannot be employed for every data flow framework. 3. A Data Flow Framework for Simple WCET In this section we define a simple data flow framework for worst case execution time analysis. The idea is based on methods for WCET analysis widely used in literature, e.g. PK89, Sha89, HS91, ITM90, GR91] In general, WCET analysis has to deal with two problems # : 1. Determine the timing behavior of if then else statements. 2. Determine the number of loop iterations. Our simple approach handles case (item 1) by defining that (roughly speaking) the WCET of an if then else statement is equal to ....

[Article contains additional citation context not shown here]

Narain Gehani and Krithi Ramamritham, Real-time Concurrent C: A language for programming dynamic real-time systems, The Journal of Real-Time Systems 3 (1991), 377--405. 2, 7, 21

....it lacks the means to express the notion of preemption[19] which can be used to conveniently model many real life situations. Further, it is a specification language as opposed to a programming language. 1. 2 Motivation and Objectives The use of existing synchronous languages like Esterel [9, 55, 52, 91, 100, 80] in implementing many real systems brought to the fore fundamental constraints in their applicability to these application domains. Example 1.1 Consider a simplified example of modeling a system consisting of a CPU and some RAM. Let us assume that the CPU runs at a faster clock than the RAM and ....

N. Gehani and K. Ramamritham. Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems. Journal of Real-Time Systems, 3:377-- 405, 1991.

....amount of stack space. In view of these problems most designers of realtime programming languages decide to forbid recursion in their languages, e.g. RT Euclid (cf. 6, 5] Supported by the Austrian Science Foundation (FWF) under grant P10188 MAT. PEARL (cf. 3] Real Time Concurrent C (cf. [4]) and the MARS approach (cf. 7, 11] Our approach is different in that we do not forbid recursion, but instead constrain recursive procedures such that their space and time behavior either can be determined at compile time and or can be checked at runtime. Thus timing errors can be found ....

N. Gehani and K. Ramamritham. Real-time Concurrent C: A language for programming dynamic real-time systems. The Journal of Real-Time Systems, 3:377--405, 1991.

....by allowing trace values to be constrained only at times between 0 and . Ideally we want a target programming language which allows timing constraints on code fragments to be expressed directly. Although a handful of programming languages with first class timing constructs have been proposed [25, 11, 10, 5], none has become widely established. Therefore, for the purposes of this paper, we target Dijkstra s guarded command language augmented with timing annotations. The definition of each executable code construct is given in Figure 1 and discussed further in this section. Note that x 2 v is a ....

N. Gehani and K. Ramamritham. Real-time concurrent C: A language for programming dynamic real-time systems. The Journal of Real-Time Systems, 3:377--405, 1991.

....an interface definition language is introduced which allows efficient analysis but does not have the expressive power of regular expressions. dfwcetklu.tex; 14 04 2000; 9:10; p.2 Data Flow Frameworks for WCET Analysis 3 4. Determining the execution time of a code segment is also mentioned in (Gehani and Ramamritham, 1991). Real time concurrent C uses a tool which originally is based on (Mok et al. 1989) 5. In (Puschner and Koza, 1989) language constructs have been introduced in order to let the programmer integrate knowledge about the actual behavior of algorithms which cannot be expressed using standard ....

....Data Flow Framework for Simple WCET In this section we define a simple data flow framework for worst case execution time analysis. The idea is based on methods for WCET analysis widely used in literature, e.g. Puschner and Koza, 1989; Shaw, 1989; Halang and Stoyenko, 1991; Ishikawa et al. 1990; Gehani and Ramamritham, 1991). In general, WCET analysis has to deal with two problems 3 : 1. Determine the timing behavior of if then else statements. 2. Determine the number of loop iterations. Our simple approach handles case (1) by defining that (roughly speaking) the WCET of an if then else statement is equal to the ....

[Article contains additional citation context not shown here]

Gehani, N. and K. Ramamritham: 1991, `Real-time Concurrent C: A language for programming dynamic real-time systems'. The Journal of Real-Time Systems 3, 377--405.

....statement for expressing lower absolute timing bounds, the before coercion gives us a programming language in which blocks of code can be bracketed by precise timing constraints. Although numerous experimental programming languages with first class timing annotations have been proposed previously [32, 6, 17, 18, 31, 7, 5] none has become widely accepted. The simple addition of the before directive to an existing language has a greater chance of industrial uptake than an entirely new language. More importantly, the before directive can be generated as a product of stepwise program refinement [10] thus supporting ....

N. Gehani and K. Ramamritham. Real-time concurrent C: A language for programming dynamic real-time systems. The Journal of Real-Time Systems, 3:377-- 405, 1991.

....may happen during execution. We consider as asynchronous any system of representation of events (some atomic abstraction such as rendez vous) that does not allow to perceive simultaneous events. Examples of asynchronous real time languages are CSP [18, 33] ADA [36, 2] and Real Time Concurrent C [13]. As the asynchronous approach relies on the observed interleaving of perceptible events during execution, this approach is implementation oriented; it forces to consider more or less abstractly the target architecture at early specification stage of the applications. Therefore, the portability ....

N. Gehani and K. Ramamrithan. Real-Time Concurrent C: a language for programming dynamic real-time systems. The Journal of Real-Time Systems, 3:377--405, 1991.

....languages, and specification languages (or formalisms) that are used to describe time constraints at the application level, or even the system level. Examples of application programming languages are Tomal [KH76] Pearl [Mar78] Real Time Euclid [KS86] RTC [ITM92] Real Time Concurrent C [GR91], Dicon [LG85] Chaos [BG92] Flex [LN88] TCEL [GH93] Ada95 [ANS95] MPL [NTA90] and CaRT Spec [WSM95] These languages include a wide variety of features that allow the compiler (and possibly run time system) to check assertions or even to transform code to ensure adherence to timing ....

N. Gehani and K. Ramamritham, Real-Time Concurrent C: A language for programming dynamic real-time systems, Journal of Real-Time Systems, 3(4):377--405, December 1991.

....have the expressive power of regular expressions. The reported examples (cf. 7] show that tight bounds can be derived using this method. On the other hand, the user must specify upper bounds for general loop statements. ffl Determining the execution time of a code segment is also mentioned in [10]. Real time concurrent C uses a tool which originally is based on [11] The code can have loops with user specified loop bounds. Summing up, most researchers try to ease the task of estimating the number of general loop iterations by forbidding general loops, i.e. by forcing the user to supply ....

....that the only thing that is known is U 2 N, an upper bound for the number of iterations of a general loop. Then we define the remainder function of a discrete loop by r i = U; r 1 = r Gamma 1: Obviously this is semantically equivalent to the approaches described in the introduction (cf. [2, 5, 7, 8, 10]) If the upper bound U is exceeded, the exception loop error is raised, which must be caught by an appropriate exception handler in order to treat this exceptional case. 2) An upper bound for the amount of time T the loop uses can be given by r i = T; r 1 = r Gamma time(loop body) 8.1) ....

N. Gehani and K. Ramamritham. Real-time Concurrent C: A language for programming dynamic real-time systems. The Journal of Real-Time Systems, 3:377--405, 1991.

....to the guarantee concept of the Spring kernel is, that a task (MainTask) can be started, even if its worst case execution time (WCET) is unknown. Only the WCET of the ExceptTask must be known. In contrast to currently used exception handling mechanisms in real time programming languages (e.g. RTC [Geh91, Wol91], RTC [Ish90] Flex [Ken91] RT Euclid [Kli86] the exception handler in our scheme is executed in order to avoid a deadline violation of the MainTask (in terms of exception handling a try block ) and not after a deadline violation has happened. In other words, it is guaranteed, that if the ....

N. Gehani, K. Ramamritham: "Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems", July 1991

....An important aspect of consideration of systems with time constrained activities is the ability to predict whether or not an activity or a set of activities will meet their timing requirements. In real time systems time constraints attached to various activities can in general be interpreted [5] as follows: 1. Critical Activities: The deadlines associated with such activities cannot be missed under any circumstances. 2. Guaranteed Activities: These are activities that need not always execute but, if executed, should be completed before their deadlines. The motivation for such activities ....

....systems are systems where all the activities are critical, i.e. all activities have to be guaranteed a priori. Dynamic real time systems are systems wherein the activities have to be guaranteed dynamically and activities can be spawned dynamically. Languages such as Real time Concurrent C [5] have been designed to cater to programming such classes of real time systems. In this paper, we show how the CRP paradigm can be effectively used for programming dynamic real time systems. The rest of the paper is organized as follows: Section 2 provides an overview of CRP and timed CRP. Section ....

[Article contains additional citation context not shown here]

N. Gehani and K. Ramamritham, Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems

....of a real time programmer. An important aspect of consideration of systems with time constrained activities is the ability to predict whether or not an activity or a set of activities will meet their timing requirements. Time constraints attached to various activities can in general be classified [5] as follows: 1.Critical Activities: Here, deadlines cannot be missed under any circumstance. 2.Guaranteed Activities: These are activities that need not always execute, but if executed The work was supported by Indo French Centre for the Promotion of Advanced Research, New Delhi. 2 Here, we ....

....connotations. Static real time systems are systems where all the activities are critical, i.e. all activities have to be guaranteed a priori. Dynamic real time systems are systems wherein the activities have to be guaranteed and spawned dynamically. Languages such as Real time Concurrent C [5] have been designed to cater to programming such classes of real time systems. In this paper, we show that the timed CRP paradigm can be effectively used for programming dynamic real time systems and in particular for (1) specifying densetime systems, 2) specifying strict timing constraints, and ....

[Article contains additional citation context not shown here]

N. Gehani and K. Ramamritham, Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems, J. of Real-Time Systems, 3, pp. 377-405, 1991.

....a means for the runtime program to evaluate whether any timing constraints have been broken. Furthermore, explicit time constraint constructs can drastically minimize coding complexity as well as analysis. Various programming language constructs for real time environments are discussed in [45, 38, 35, 28, 27, 26, 20, 16, 14, 43]. 6.1 Construct for the Expression of Time Defined Delays In the Ada programming language[25, 48] a time defined delay is expressed by either of two constructs: delay delaytime delay until delaytime CHAPTER 6. REAL TIME CONSTRUCTS 73 delay specifies a delay time relative to the outset of the ....

N. Gehani and K. Ramamritham. Real-time Concurrent C: A language for programming dynamic real-time systems. Real-Time Systems, 3(4):377--405, December 1991.

.... is Real Time Concurrent C, which has added constructs to Concurrent C for specifying periodicity or other timing constraints, to seek guarantees that the timing constraints will be met, and to perform alternative actions when either the alternative actions or the guarantees are not available [19]. The language provides a reasonable vocabulary for specifying the real time behavior that is desired, but since the current implementation manages multiple execution threads within a single UNIX process, there are limits to how predictable the language can be made and the strength of the ....

Gehani, N. and Ramamritham, K. Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems. Real-Time Systems Journal, 3(4):377--406, December 1991.

....of overload, support n classes, provide a minimum level of guarantee even in overload, allow deadline tolerance, more formally address resource reclaiming, and provide performance data for the impact of re guarantees. We also formally prove all our main results. Finally, Gehani and Ramamritham [Geh 91] propose programming language features to allow specification of deadline and a deadline slop factor (similar to our deadline tolerance) but propose no algorithms for supporting this feature. 8 Conclusions We have developed a robust earliest deadline scheduling algorithm for hard real time ....

N. Gehani and K. Ramamritham, "Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems," Real-Time Systems, 3, pp. 377-405, 1991.

....code and capable of specifying reflective information such as timing requirements (deadlines, periods, etc. and the need for guarantees with respect to these requirements. In the spirit of research, we have developed two versions of such languages, Spring C [15] and Real Time Concurrent C (RTCC) [5]. Spring C is currently implemented and used with our current overall reflective system implementation. However, it is very simple. In parallel, together with colleagues at ATT Bell Labs, we have developed a more sophisticated real time language with the necessary features for timing specification ....

N. Gehani and K. Ramamritham, Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems, Real-Time Systems, Vol. 3, No. 4, Dec. 1991.

No context found.

N.Gehani, K.Ramamrithan, \Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems," Journal of Real Time Systems, No.3, 1991.

No context found.

Gehani, N., and Ramamritham, K. Real-time Concurrent C: A language for programming dynamic real-time systems. Journal of Real-Time Systems 3, 4 (Dec. 1991), 377-405.

No context found.

GR91. Narain Gehani and Krithi Ramamritham, Real-time Concurrent C: A language for programming dynamic real-time systems, The Journal of Real-Time Systems 3 (1991), 377--405.

No context found.

N. Gehani and K. Ramamritham, Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems, Real-Time Systems, Vol. 3, No. 4, December 1991.

No context found.

Geh91. Gehani, N. and Ramamritham, K., "Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems", Real Time Systems 3(4), pp. 377-405 (December 1991).

No context found.

N. Gehani and K. Ramamritham, Real-Time Concurrent C: A Language for Programming Dynamic Real-Time Systems, Real-Time Systems, Vol. 3, No. 4, December 1991.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC