From: Jean-Francois Panisset (panisset++at++discreet.com)
Date: 04/19/2001 17:10:53
<200104180900.CAA22432++at++holodeck.engr.sgi.com>info-performer Mailing List write
s
>
> From: "Volz, Bill (WRVO)" <WRVO++at++chevron.com>
> Date: Tue, 17 Apr 2001 06:14:30 -0700
> Subject: general SGI Question: malloc thread-safe?
>
>A slightly off topic question: Is malloc thread safe?
>
>I have an app that allocates memory in the main and frees it in a thread
>before it dies. I'm getting symptoms of memory corruption. When I free the
>memory in the main, the problems disappear. The books I have installed show
>thread occurring only three times and none of the man pages on malloc says
>anything about threading. I tried malloc_ss.so and it didn't indicate any
>memory problems, even though they still occurred. The man page for pthreads
>indicate malloc is not thread safe since sbrk is not thread safe, but it
>doesn't say anything about free.
>
>What about fwrite? Are the I/O routines thread safe (assuming only one
>thread is writing to a stream).
As a general rule, libc is thread-safe (apart from functions which are
implicitly not re-entrant, such as functions which return a pointer
to an internal buffer, usually there is an _r version of these functions).
But the way it is made thread safe is pretty coarse: the first time
your app calls sproc(), libc creates a big lock, and every time you
enter a libc function, the lock is acquired and then released, so
only one sproc can be in libc at any one time. In particular, if you
are playing around with real-time process priorities and CPU assignments,
it is fairly easy to get into deadlock/priority inversion situations.
Especially with malloc, since pretty much everything ends up calling
malloc, even things like OpenGL (unfortunately).
You may want to look at replacement malloc libraries. A very good
commercial offering is SmartHeap, but unfortunatly it doesn't work
with sproc-based applications, only pthreads-based, so I don't know
if you could get this to work with Performer. SmartHeap uses
compare-and-swap instructions to implement a fully re-entrant,
MP-scalable malloc.
Over the years, I'd say that malloc has been the single biggest source
of system-level headaches I've run into... And it looks so simple...
JF
This archive was generated by hypermail 2b29 : Thu Apr 19 2001 - 17:11:00 PDT