[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] Allocation in HRT
From:       Alexis.P.Wieland () disney ! com (Wieland, Alexis P)
Date:       2009-10-26 16:38:09
Message-ID: B0BFA5991B07A441BA14A96D6055E0B10B502D () SM-CALA-VXMB02B ! swna ! wdpr ! disney ! com
[Download RAW message or body]

> From: Stephen Roderick [mailto:kiwi.net at mac.com] 
> On Oct 26, 2009, at 12:16 , Wieland, Alexis P wrote:
> >
> >> From: S Roderick [mailto:kiwi.net at mac.com]
> >> On Oct 24, 2009, at 15:45 , alexis at disney.com wrote:
> >>
> >>> Well, I was told these were discussions were appropriate for the
> >>> whole group, so here goes.  Continuing another off ML discussion:
> >>>
> >>>>> To be honest using heap in hard real-time, even TLSF, is
> >>>>> intriguing but
> >>>>> not something I've ever been willing to use "for real".
> >>>>
> >>>> Can you name a hard real-time os that offers messaging but that
> >>>> doesn't use any kind of allocator in the critical path ?
> >>>
> >>> Fascinating, I thinking this must be semantic.  While I'm
> >> willing to
> >>> say its painful, limiting, and uses RAM inefficiently, isn't the
> >>> answer "All of them" ?
> >>>
> >>> After careful analysis and testing, create generously sized
> >> rt fifos
> >>> or other buffered I/O channels.  It's a catastrophic error for the
> >>> buffer to overflow.  Even when communicating with non-RT the basic
> >>> approach works fine (you just get really big buffers "just in
> >>> case").  For a couple extra dollars in RAM you get rock
> >> solid.  For
> >>> my applications it's appropriate, YMMV.
> >>
> >> But it isn't always possiible to add more RAM. I have worked on
> >> embedded systems where we used virtually every single byte of
> >> RAM. We
> >> couldn't afford over-sized buffers, just in case. I'm just
> >> saying that
> >> your example approach doesn't always apply.
> >
> > I think we're agreeing, it doesn't *always* apply.
> > I just don't want you to preclude me from meeting
> > what in some cases are design requirements.
> 
> Fair enough.
> 
> > My understanding is if the logger is implemented in the way
> > that's currently planned, and then used in the core of RTT
> > (as I'd hope the logger would be), you will have made it
> > difficult to not have resource management in critical paths.
> 
> I think this last concern is in everyone's mind, including 
> mine. We'll  
> have to tread carefully when we get there ... I don't know 
> how this is  
> going to work out yet. But also, Peter has indicated that such  
> resource management will be required in RTT for other 
> pursposes too ...
> 
> Stephen
> 

The question for me then becomes is Orocos acceptable to use.

- alexis.


[prev in list] [next in list] [prev in thread] [next in thread]