Re: Are g_try_malloc() and g_free() thread-safe?
- From: stian nixia no
- To: "Christ, Bryan" <bryan christ hp com>
- Cc: gtk-list gnome org
- Subject: Re: Are g_try_malloc() and g_free() thread-safe?
- Date: Mon, 7 Feb 2005 21:45:44 +0100 (CET)
> 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.
> If these functions lock the heap during memory allocations and releases
> then my wrappers are pointless. However, I have noticed that when I
> don't use the global mutex wrapper, g_try_malloc will often return an
> invalid address (not NULL as documented) or my data will be corrupt when
> it is access across threads.
That should not happen.
> Basically, my application has several threads which push and pop
> "messages" to/from a linked-list. The data (message) for each node is
> allocated from the heap when it is "pushed" and freed by the processing
> loop when it is "popped". The result is that there can be several
> hundred messages which are allocated and freed within a very microscopic
> time frame. Since my linked-list is independently locked
> (g_static_mutex_lock), I am confident the problem lies outside the list
In that case. there is a glib but out there. Atleast that is my toughts.
] [Thread Prev