problem with memory allocation

[joel at OARcorp.com (joel at OARcorp.com)]

On Tue, 3 Aug 1999, D. V. Henkel-Wallace wrote:

> At 11:03 03-08-99 -0500, joel at OARcorp.com wrote:
> >On Tue, 3 Aug 1999, D. V. Henkel-Wallace wrote:
> >
> > > At 10:26 03-08-99 -0500, joel at oarcorp.com wrote:
> > > >malloc is built on top of Region which is built on top of a Heap.
> > >
> > > Does anybody on this list actually take advantage of this layering?
> >
> >I will actually go so far as to say that virtually no one has ever had
> >multiple regions in the same application.
> >
> >The only cases I can think of are where the second region was used to
> >manage some special purpose memory.
> 
> Yes, this is the only case I can imagine; in fact your example is really a 
> special-case of it.
> 
> So what I really should have asked: could we just collapse this 
> stacking...perhaps eliding regions?
> 
> Does orkid require it?  And if so, does that matter any more?

Yes.  And probably not, except for compatability with applicaitons that
use the RTEMS Region as well as compatability with pSOS+ and VMEexec.

If the RTEMS malloc implementation were replaced with one based on a
binary semaphore and a SuperCore heap, nothing would be lost.  We could
leave the Region Manager as is for compatibility and it would just reduce
the footprint of an RTEMS application.

Which brings up an issue I have wanted to through out for a while. :)

Ian (and others including myself) have complained that RTEMS semaphores
are heavy handed.  They are (rightly) used in numerous chunks of RTEMS
support code (including termios and libio).  But 90% of the time, these
support components do not require the full functionality of the RTEMS
Classic semaphores.  Would we be better off with a light-weight RTEMS
specific mutex that was malloc'ed -- not configured?  Perhaps a thin layer
over the SuperCore Mutex. 

Comments.

--joel