Re: threaded malloc

[Joel Sherrill <joel@OARcorp.com>]

On Thu, 4 Dec 1997, Ian Lance Taylor wrote:

> I'm looking into replacing the current implementation of malloc in
> newlib with one that is more suitable for embedded use.
> 
> One thing I've noticed is that the current newlib malloc stores its
> data in the thread reentrancy structure.  That doesn't make much sense
> for malloc.  It would seem more normal for all threads to share the
> same malloc pool, with some sort of per-thread locking.
> 
> Does anybody see any problems with changing this?  I don't know
> whether anybody actually uses the reentrancy stuff anyhow.

If there is an archive of this mailing list, then you might find some
discussion between myself, Tony Bennett, and Rob Savoye about the
reentrancy design of newlib and ohw it could be improved.  The key to the
current newlib reentrancy is that each thread gets its own copy of all
"sensitive" data.  Some of this data is really global and should be
shared/protected.  The malloc data is the worst example of this.  Each
thread should not have its own malloc area.  They should share one larger
protected area.

FYI RTEMS does use the newlib reentrancy stuff but we replace the malloc
algorithm with something of our own using a variable memory allocator
which was included in the original specification RTEMS was based upon.
I would love to see the newlib reentrancy stuff upgraded to include the
concept of semaphores/mutexes and have the malloc use that.

AFAIK RTEMS users reflect a significant percentage of the newlib
user community.

I have offered in the past to help someone at Cygnus setup an RTEMS
environment on sis (sparc simulator) to help test embedded issues.  RTEMS
is a good candidate for testing many of these embedded type issues.  

--joel