threaded malloc

Joel Sherrill
Mon Dec 8 11:49:00 GMT 1997

On Mon, 8 Dec 1997, Ian Lance Taylor wrote:

>    Date: Thu, 4 Dec 1997 12:45:10 -0600 (CST)
>    From: Joel Sherrill <>
>    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.
> I reworked the newlib malloc to incorporate Doug Lea's malloc routine
> ( ).  I changed the routines to
> use a single heap.  The reentrancy pointer is still passed into the
> malloc routines (and on to _sbrk_r) so we can in the future change
> this around if we like.
> malloc and friends now call __malloc_lock and __mallock_unlock around
> accesses to the heap, so that it is possible to lock it for multiple
> threads.  The default versions of __malloc_lock and __malloc_unlock do
> nothing.

Is there going to be a newlib snapshot I can get access to to try this
out?  We would be happy to use this malloc. This sounds like a big win. 

Do __malloc_lock and __malloc_unlock live in libgloss?

>    AFAIK RTEMS users reflect a significant percentage of the newlib
>    user community.
> The other big user that I know of is the cygwin32 project, which uses
> newlib on Windows.

That probably represents more users than RTEMS. :)  

But we still cover more CPUs. 


More information about the Newlib mailing list