threaded malloc
Joel Sherrill
joel@OARcorp.com
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 <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
More information about the Newlib
mailing list