This is the mail archive of the newlib@sourceware.cygnus.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: threaded malloc




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

>    Date: Thu, 4 Dec 1997 12:45:10 -0600 (CST)
>    From: Joel Sherrill <joel@OARcorp.com>
> 
>    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
> (http://g.oswego.edu/dl/html/malloc.html).  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. 

--joel