Re: Are g_try_malloc() and g_free() thread-safe?

[Ben Johnson <ben blarg net>]

On Mon, Feb 07, 2005 at 09:45:44PM +0100, stian nixia no wrote:
> > Can anyone say with certainty whether g_try_malloc() and g_free() are
> > thread-safe?  I've spent considerable time searching mailing lists and
> > googling and have found only sketchy opinions at best.
> 
> glib itself is thread safe, while the user-side is not. g_malloc and
> g_free is thread safe. a GList for instance is not.
> 
> > Historically, I have been wrapping all of my allocations and releases in
> > a global mutex, but this seems far from optimal.  I assume that these
> > functions are implementations of malloc() and free(), but again it seems
> > there is no definitive answer to my question.
> 
> malloc and free are not thread-safe unless you define _REENTRANT or such
> alike. g_malloc/g_free do not wrap around malloc/free. glib has its own
> internal memory management as far as I know.

I just looked at glib/gmem.c a bit.  As far as I can tell, g_malloc()
and g_free() *are* just simple wrappers for malloc() and free().  It's
possible to change that with a call to g_mem_set_vtable(), but unless
that's happening by default...  g_malloc() and g_free(), I'd say, are
just as thread safe as malloc() and free().  g_try_malloc() and
g_malloc() appear to be more or less identical (if not actually #defined
that way).  Maybe I'm missing something.

What are the threading risks in malloc() and free()?  I suppose they
both mess with some global pointers and call (...or by calling) brk().

how do you remove the risk?  you have to compile libc with _REENTRANT?

Also, the g_mem_set_vtable() function does not appear to be thread safe.
I imagine that's not an issue in this instance, but makes me question
the claim that all of glib is thread safe.

- Ben