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] |
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