FreeBSD 9.1 excessive memory allocations [SOLVED]
jdc at koitsu.org
Thu Mar 28 07:04:23 UTC 2013
On Wed, Mar 27, 2013 at 10:39:16PM -0700, Unga wrote:
> > I think you may be reading too much into the malloc manpage.? When it
> > mentions the use of per-thread small-object caches to avoid locking it's
> > talking about performance, not thread safety.? Allocations of all sizes
> > are thread-safe, the library just assumes that huge allocations are rare
> > enough that it doesn't use extra per-thread resources to avoid locking
> > for them, it just uses locking for huge blocks.
> > -- Ian
> Good to note all allocations are thread safe in FreeBSD. Is it by some
> standard that malloc should be thread safe regardless the OS (BSDs,
> Linux, Windows, Android, etc)?
The Internet is sometimes a useful resource.
On the BSDs, with gcc -pthread you should be fine. Don't ask me about
On Linux, glibc's routines are apparently thread-safe barring if the
software was built with -DNO_THREADS (which seems very unlikely given
the risks). Android is Linux.
On Windows, assuming you're using CRT libraries, the routines are
thread-safe. I get the impression the threaded library versions are
also thread-safe for their *alloc equivalents. I believe HeapAlloc is
thread-safe, and am pretty sure Global* is thread-safe (barring very
very old Wine environments).
Solaris's routines are also thread-safe, barring you're using standard
malloc and not mtmalloc or ptmalloc or libumem (try searching the web
for things like "Solaris mtmalloc" and read).
All these OSes in some way or another have support for multi-threaded
malloc implementations for increased performance (this is separate from
locking/lock contention) where, AFAIK, you get to do the locking
| Jeremy Chadwick jdc at koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
More information about the freebsd-stable