From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,31269dcc0261900b,start X-Google-Attributes: gid1014db,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public From: "Nick Roberts" Subject: Real-time dyn allctn (was: Ada vs C++ vs Java) Date: 1999/01/25 Message-ID: <78i6m3$505$4@plug.news.pipex.net>#1/1 X-Deja-AN: 436727945 References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <77mu1h$n6m$1@galaxy.mchh.siemens.de> <77no7p$d65$1@nnrp1.dejanews.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom) Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java,comp.lang.c,comp.realtime Date: 1999-01-25T00:00:00+00:00 List-Id: Michael J. Tobler wrote in message ... | |> In article <77mu1h$n6m$1@galaxy.mchh.siemens.de>, |> Wolfgang Denk wrote: |> > |> > But even under hard realtime you certainly will very |> > often use dynamic memory allocation - all variables put |> > on the stack are using a method of "dynamic memory |> > allocation" | |This is an incorrect statement. The stack is a static area of storage. |Objects, both native and user-defined are simply defined there and the |stack pointer is adjusted appropriately. There is no concept of "searching |for available memory", allocating it, and recording it - the memory |reserved for the stack is "allocated" at startup. Michael's comment is not strictly correct. In the general case, the pattern of calls that will be made during the execution of a program - even a 'hard' real-time one - will be unpredictable (because it depends on unpredictable input values). The maximum possible stack usage can be calculated. However, this figure will often be vastly greater than any stack usage that will occur in practise (and thus be useless). The occurance of recursion which is controlled by an input value usually makes the aforementioned effect inevitable. The allocation of data within a stack frame may well be static (but not necessarily). There is a certain, small, subset of programs which have a statically predictable pattern of stack allocation, and thus a memory requirement which is statically determinable with little or no waste. But it is misleading to describe allocation on the stack as 'static': it is generally nothing of the kind. I also feel that the sentiment "don't use dynamic allocation in real-time programs" is somewhat naive, to put it mildly. I rather suspect that, in rejecting the use of 'malloc' or 'new', the programmer simply replaces these forms of dynamic allocation with others (a statically declared array used to hold dynamically changing data, for example), for no better reason than superstition. There is no need to take this attitude for any kind of program. Taking the example of a program which flies an aeroplane, you will want to adopt a strategy of absolute robustness ('never crash'). [1] This means that, if the program uses dynamic allocation, either it must be possible to statically determine that memory will never be insufficient, or there must be a means of: (a) reliably detecting insufficient memory; and (b) upon detecting this, returning the software to a state that enables it to continue safely flying the aeroplane. These requirements are not usually impractical to achieve. [2] If the software has interrupt servicing time constraints, the interrupt servicing routines which have these constraints must either: (a) be able to use the dynamic allocation in a way which is predictably fast enough; or (b) not use dynamic allocation. These conditions do not need to be imposed on any of the other parts of the software (if there are any). It may well be that typical supplied dynamic allocation facilities are too crude or unreliable to satisfy the special requirements of a real-time program. But the answer is not to simply abandon the use of 'malloc' and replace it with a large number of ad-hoc, hybrid solutions (involving arrays and indexes). Instead, all that is required is to reprogram the dynamic allocation facilities to your requirements: you may need a 'malloc_a', a 'malloc_b', and a 'malloc_c', or whatever. The result is likely to be better source code and better performing software, with no reduction in robustness. In addition, in view of my comments earlier in this posting about the dynamic nature of allocation on the stack, it will often be the case that my comments above about dynamic allocation can be applied to stack allocation as well (saving a lot of memory space wasted on making sure the stack cannot crash). ------------------------------------------- Nick Roberts -------------------------------------------