Is malloc() function provided in <stdlib.h> thread-safe?

Guest

Hi all,
Does anyone have experience on the thread-safty issue with malloc()?
Some people said this function provided in stdlib.h is not thread-
safe, but someone said it is thread safe. Is it possible this
function evolves from thread-unsafe to thread-safe in recent years?
How could i find out?
I am using the C library coming with GNU linux distribution.

Advertisements

In article <>,
<> wrote:
> Does anyone have experience on the thread-safty issue with malloc()?
>Some people said this function provided in stdlib.h is not thread-
>safe, but someone said it is thread safe. Is it possible this
>function evolves from thread-unsafe to thread-safe in recent years?
>How could i find out?

The C standards have no concept of threads or thread safety, so
unless you define threads vacuously, one must assume that there
will be platforms on which malloc() is *not* thread safe.
> I am using the C library coming with GNU linux distribution.

If you want to know about whether malloc() is thread-safe in the
particular distribution you are using, then ask in a newsgroup
or mailing list that deals with that particular distribution.
The answer for C as a whole is "NO". It could be that the
answer for all platforms that you are interested in is "Yes", but
that would be due to implementation-specific behaviour, not behaviour
mandated by C.
--
"For men are prone to go it blind along the calf-paths of the
mind To do what other men have done. They follow in the beaten
track, and out and in, and forth and back, and still their
devious course pursue, to keep the path that others do." -- Sam Walter Foss

Advertisements

wrote:
> Hi all,
> Does anyone have experience on the thread-safty issue with malloc()?
> Some people said this function provided in stdlib.h is not thread-
> safe, but someone said it is thread safe. Is it possible this
> function evolves from thread-unsafe to thread-safe in recent years?
> How could i find out?
> I am using the C library coming with GNU linux distribution.
>
Then check your man pages.

In comp.lang.c, wrote:
> Hi all,
> Does anyone have experience on the thread-safty issue with malloc()?

Possibly. In any case, "thread-safety" is irrelevant here. The C standard
does not include "threads", and does not address whether a specific library
function is "thread-safe" or not.

However, your C compiler /implementation/ may recognize "threads" in your
environment. To determine if your /implementation/ supplies "thread-safe"
standard library functions, you should check your /implementation's/
documentation or ask about the subject in the appropriate /implementation/
forum.
> Some people said this function provided in stdlib.h

stdlib.h does not provide any function. It provides function declarations
(prototypes for the function's calling parameters and return value),
macros, and other sort of information. The /function/ will be provided in
one of your implementation's libraries.
> is not thread-safe, but someone said it is thread safe.

"Some people" "Someone"? How about asking the implementers, or checking the
implementation documentation? Remember, even here, we are "some people",
and I am "someone".
> Is it possible this
> function evolves from thread-unsafe to thread-safe in recent years?

It is, in any specific implementation. An implementation can even offer both
thread-safe and thread-unsafe versions of the same function, so long as the
mechanism that selects the function is outside of the C language (like a
compiler or linker option, or the specification of an alternate library
during linkage).
> How could i find out?

<OT>
Assuming a recent version of GCC and a recent implementation of Linux, you
have may have
1) no threading support at all,
2) "Linux threads" support, or
3) "NPTL" threads support

"Linux Threads" and "NPTL threads" runtimes are implemented in different
(non-C-standard) libraries, which provide both the threading primative
functions and (possibly) "thread-safe" replacement functions for some
thread-unsafe functions in the standard and POSIX libraries.

If your environment does not include either "Linux Threads" or "NPTL"
threads, then you likely have a C runtime library that does not recognize
threads, and thus has a questionable "thread-safety" (functions /may/ be
thread-safe, but there is no guarantee). Check your /usr/doc/gcc*
documentation, and the manpage for each function you intend to use, and
look for the instructions on how to use the appropriate threading library.
</OT>
> thanks a lot.
>
> tony

On Apr 25, 1:12 pm, wrote:
> Hi all,
> Does anyone have experience on the thread-safty issue with malloc()?

Yes. To implement a thread without a thread-safe malloc is a
practically meaningless concept. Any system which does not support
this, cannot seriously call itself supporting of multi-threading.
> Some people said this function provided in stdlib.h is not thread-
> safe, but someone said it is thread safe.

As I said, a multi-threading environment without a thread-safe malloc
is basically a worthless and unusable environment. Typically, malloc/
free etc is designed to be thread safe, then the threads themselves
allocate their auto space and return stack space via an malloc. So
you can see that the two concepts of memory management and thread
management as dependent on each other. You can't really have one
without the other in a multi-threading environment.
> How could i find out?
> I am using the C library coming with GNU linux distribution.

On Fri, 25 Apr 2008 20:12:46 UTC, wrote:
> Hi all,
> Does anyone have experience on the thread-safty issue with malloc()?
> Some people said this function provided in stdlib.h is not thread-
> safe, but someone said it is thread safe. Is it possible this
> function evolves from thread-unsafe to thread-safe in recent years?
> How could i find out?
> I am using the C library coming with GNU linux distribution.

On my implementation malloc is threadsave - or not. It depends simply
on the library bounded to the the executeable.

The implementation serves the same functionality in 4 different
libraries:
1. single CPU, single threaded
highly optimised under the premise that the application runs only
for its own using only one thread on one CPU
The process using this library has no interaction outside its
own single threaded process.
2. single CPU, multithreaded
highly optimised under the premise that the app has no need to
coordinate multiple CPUs but can run multiple threads sharing the
same CPU
3. multiple CPU, singlethreaded
highly optimised under the premise that the app has no need to
run multiple threads of its own but my have the need to
coordinate with other app running on other CPU
4. multiple CPU, multithreaded
data can be shared between multiple CPUs running multiple threads.

So the developer tells the linker which of the library variant he
needs.

On 25 Apr 2008 at 22:33, CBFalconer wrote:
> Paul Hsieh wrote:
>> wrote:
>>
>>> Does anyone have experience on the thread-safty issue with malloc()?
>>
>> As I said, a multi-threading environment without a thread-safe malloc
>> is basically a worthless and unusable environment. Typically, malloc/
>> free etc is designed to be thread safe, then the threads themselves
>> allocate their auto space and return stack space via an malloc. So
>> you can see that the two concepts of memory management and thread
>> management as dependent on each other. You can't really have one
>> without the other in a multi-threading environment.
>
> It is perfectly possible to use a non-thread-safe malloc in a
> thread-safe manner. It is necessary that the OS have a system call
> that will prevent thread changes, say "thread_lock()". This will
> also require a corresponding call, say "thread_unlock()".
>
> Then, to use anything in the malloc group, you simply write:
>
> thread_lock();
> p = malloc(N * sizeof *p);
> thread_unlock();
>
> and you have pushed all the hard stuff off to the system designer.

You really don't have the first, tiniest inkling of a clue what you're
talking about, do you?

To the OP, please listen to the common-sense words of Paul Hsieh quoted
above. *Of course* there isn't a single C threads implementation that
doesn't come with a threadsafe malloc(): what would be the point of
using threads if the cost was not being able to do something as
fundamental as allocating memory?

Antoninus Twink <> writes:
> On 25 Apr 2008 at 22:33, CBFalconer wrote:
>> Paul Hsieh wrote:
>>> wrote:
>>>
>>>> Does anyone have experience on the thread-safty issue with malloc()?
>>>
>>> As I said, a multi-threading environment without a thread-safe malloc
>>> is basically a worthless and unusable environment. Typically, malloc/
>>> free etc is designed to be thread safe, then the threads themselves
>>> allocate their auto space and return stack space via an malloc. So
>>> you can see that the two concepts of memory management and thread
>>> management as dependent on each other. You can't really have one
>>> without the other in a multi-threading environment.
>>
>> It is perfectly possible to use a non-thread-safe malloc in a
>> thread-safe manner. It is necessary that the OS have a system call
>> that will prevent thread changes, say "thread_lock()". This will
>> also require a corresponding call, say "thread_unlock()".
>>
>> Then, to use anything in the malloc group, you simply write:
>>
>> thread_lock();
>> p = malloc(N * sizeof *p);
>> thread_unlock();
>>
>> and you have pushed all the hard stuff off to the system designer.
>
> You really don't have the first, tiniest inkling of a clue what you're
> talking about, do you?

I find it astonishing that he is tolerated at all by the regs. He is a
typical know nothing blow hard where a little bit of knowledge shows
itself to be a very dangerous thing. Second only to Default User in
useless net nanny posts I wonder what it is that makes him post at
all.
>
> To the OP, please listen to the common-sense words of Paul Hsieh quoted
> above. *Of course* there isn't a single C threads implementation that
> doesn't come with a threadsafe malloc(): what would be the point of
> using threads if the cost was not being able to do something as
> fundamental as allocating memory?

Exactly. But maybe Falconer is being thick on purpose - he can state
that he is not a "threads guy" and that they are dealt with down the
"corridor on the right".

[ ... ]
> 1. single CPU, single threaded
> highly optimised under the premise that the application runs only
> for its own using only one thread on one CPU
> The process using this library has no interaction outside its
> own single threaded process.
[ ... ]
> 3. multiple CPU, singlethreaded
> highly optimised under the premise that the app has no need to
> run multiple threads of its own but my have the need to
> coordinate with other app running on other CPU

Just curious here, what's the difference between these two? How does
coordintaion with other treads affect malloc?

In article <>,
Antoninus Twink <> wrote:
>>> wrote:
>>>> Does anyone have experience on the thread-safty issue with malloc()?
>*Of course* there isn't a single C threads implementation that
>doesn't come with a threadsafe malloc(): what would be the point of
>using threads if the cost was not being able to do something as
>fundamental as allocating memory?

The original poster asked a general question about thread-safety
in malloc(), not one restricted to systems with threads implementations.
--
"I buy more from my grocer than he buys from me, and I bet it's
the same with you and your grocer. That means we have a trade
deficit with our grocers. Does our perpetual grocer trade deficit
portend doom?" -- Walter Williams

Guest

On Apr 26, 2:18 pm, -cnrc.gc.ca (Walter Roberson)
wrote:
> In article <>,
> Antoninus Twink <> wrote:
>
> >>> wrote:
> >>>> Does anyone have experience on the thread-safty issue with malloc()?
> >*Of course* there isn't a single C threads implementation that
> >doesn't come with a threadsafe malloc(): what would be the point of
> >using threads if the cost was not being able to do something as
> >fundamental as allocating memory?
>
> The original poster asked a general question about thread-safety
> in malloc(), not one restricted to systems with threads implementations.

Amazing. You could tell that OP *could* ask about
nonsense like that (we are in comp.lang.c, so we
may not assume that the OP is not dumb, right? He
could be dumb, "we don't know"). But claiming that
he *did* ask such a stupid thing is a little too
much, isn't it?

CBFalconer wrote:
> wrote:
>> Does anyone have experience on the thread-safty issue with malloc()?
>> Some people said this function provided in stdlib.h is not thread-
>> safe, but someone said it is thread safe. Is it possible this
>> function evolves from thread-unsafe to thread-safe in recent years?
>> How could i find out?
>>
>> I am using the C library coming with GNU linux distribution.
>
> That depends on the system and the library. It is probably not
> thread-safe.

What brings you to that conclusion? An environment with threads but
without a thread safe malloc would be about as much use as a fart in a
wetsuit.

CBFalconer wrote:
> Ian Collins wrote:
>> CBFalconer wrote:
>>> wrote:
>>>
>>>> Does anyone have experience on the thread-safty issue with malloc()?
>>>> Some people said this function provided in stdlib.h is not thread-
>>>> safe, but someone said it is thread safe. Is it possible this
>>>> function evolves from thread-unsafe to thread-safe in recent years?
>>>> How could i find out?
>>>>
>>>> I am using the C library coming with GNU linux distribution.
>>> That depends on the system and the library. It is probably not
>>> thread-safe.
>> What brings you to that conclusion? An environment with threads but
>> without a thread safe malloc would be about as much use as a fart in
>> a wetsuit.
>
> Both are useful. For malloc, consider putting all the malloc
> (free, calloc, realloc) calls in just one thread.

You are joking, right?
> Don't confuse threads and processes, which are all OT here.
>
I'm hardly likely to confuse what I spend most of my time doing.

On Sat, 26 Apr 2008 18:18:06 UTC, Øyvind Røtvold <>
wrote:
>
> "Herbert Rosenau" <> writes:
>
> [ ... ]
> > 1. single CPU, single threaded
> > highly optimised under the premise that the application runs only
> > for its own using only one thread on one CPU
> > The process using this library has no interaction outside its
> > own single threaded process.
> [ ... ]
> > 3. multiple CPU, singlethreaded
> > highly optimised under the premise that the app has no need to
> > run multiple threads of its own but my have the need to
> > coordinate with other app running on other CPU
>
> Just curious here, what's the difference between these two? How does
> coordintaion with other treads affect malloc?

1. process runs in a nutshell, no interprocesscommunication.
2. process shares something between other processes.

Multithreading on real multithreead OS has nothing in common with
pthreads. The OS is based on threads and the OS sheduler shedules
threads, not processes. There is a difference with multiprocessing
with threads in userspace and preemptive multithreading.

malloc in single threaded local environment is uninterruptable as it
is noways reentrant. malloc in multithreaded environment is
intrruptable between (and sometimes even during) single instructions
and so it must be reentrant because multiple threads can call malloc
while another threads are inside malloc. In an multicpu environment
there are multiple threads of the same process simultanous active in
malloc.

Oops, sorry, 'thread' here should be changed top 'apps', which I assume
means processes.

My question was intended to relate to the claim that there was a
difference between single threaded in a single CPU system and single
threaded in a multiple CPU system. This was clear from the points
that I quouted, but not from my question, my bad :-/.

On 27 Apr 2008 at 6:05, CBFalconer wrote:
> Ian Collins wrote:
>> CBFalconer wrote:
>>> Ian Collins wrote:
>>>> What brings you to that conclusion? An environment with threads
>>>> but without a thread safe malloc would be about as much use as a
>>>> fart in a wetsuit.
>>>
>>> Both are useful. For malloc, consider putting all the malloc (free,
>>> calloc, realloc) calls in just one thread.
>>
>> You are joking, right?
>
> Not at all. What's so hard about that? I maintain that having the
> malloc system available is useful.

You're in a hole - stop digging.

It's completely obvious to everyone reading this thread that you've
never written a multithreaded program in your life, and only have the
vaguest idea what it would entail. But for some reason that doesn't stop
you pontificating on the subject, parading your ignorance and spreading
misinformation.

Øyvind Røtvold <> writes:
> "Herbert Rosenau" <> writes:
>
> [ ... ]
>> 1. single CPU, single threaded
>> highly optimised under the premise that the application runs only
>> for its own using only one thread on one CPU
>> The process using this library has no interaction outside its
>> own single threaded process.
> [ ... ]
>> 3. multiple CPU, singlethreaded
>> highly optimised under the premise that the app has no need to
>> run multiple threads of its own but my have the need to
>> coordinate with other app running on other CPU
>
> Just curious here, what's the difference between these two? How does
> coordintaion with other treads affect malloc?
--------------------------^^^^^^
Bummer, should have been:

"Herbert Rosenau" <> writes:
> On Sat, 26 Apr 2008 18:18:06 UTC, Øyvind Røtvold <>
> wrote:
>
>>
>> "Herbert Rosenau" <> writes:
>>
>> [ ... ]
>> > 1. single CPU, single threaded
>> > highly optimised under the premise that the application runs only
>> > for its own using only one thread on one CPU
>> > The process using this library has no interaction outside its
>> > own single threaded process.
>> [ ... ]
>> > 3. multiple CPU, singlethreaded
>> > highly optimised under the premise that the app has no need to
>> > run multiple threads of its own but my have the need to
>> > coordinate with other app running on other CPU
>>
>> Just curious here, what's the difference between these two? How does
>> coordintaion with other treads affect malloc?
>
> 1. process runs in a nutshell, no interprocesscommunication.
> 2. process shares something between other processes.
>
> Multithreading on real multithreead OS has nothing in common with
> pthreads. The OS is based on threads and the OS sheduler shedules
> threads, not processes. There is a difference with multiprocessing
> with threads in userspace and preemptive multithreading.
>
> malloc in single threaded local environment is uninterruptable as it
> is noways reentrant. malloc in multithreaded environment is
> intrruptable between (and sometimes even during) single instructions
> and so it must be reentrant because multiple threads can call malloc
> while another threads are inside malloc. In an multicpu environment
> there are multiple threads of the same process simultanous active in
> malloc.

The last part here relates to multi threaded, multi CPU, point 3.
which I quoted above relates to single threaded, multi CPU. I dont
see how this would differ from point 1. single threaded, single CPU
and so was just curious as to how this affects optimisation.

CBFalconer wrote:
> Ian Collins wrote:
>> CBFalconer wrote:
>>> Ian Collins wrote:
>>>
> .... snip about thread safe malloc ...
>>>>> That depends on the system and the library. It is probably not
>>>>> thread-safe.
>>>> What brings you to that conclusion? An environment with threads
>>>> but without a thread safe malloc would be about as much use as a
>>>> fart in a wetsuit.
>>> Both are useful. For malloc, consider putting all the malloc
>>> (free, calloc, realloc) calls in just one thread.
>> You are joking, right?
>
> Not at all. What's so hard about that?

It's a ridiculous constraint to put on a threaded application design.
> I maintain that having the malloc system available is useful.
>
A thread safe one, yes.

CBFalconer <> writes:
> Ian Collins wrote:
>> CBFalconer wrote:
>>> wrote:
>>>
>>>> Does anyone have experience on the thread-safty issue with malloc()?
>>>> Some people said this function provided in stdlib.h is not thread-
>>>> safe, but someone said it is thread safe. Is it possible this
>>>> function evolves from thread-unsafe to thread-safe in recent years?
>>>> How could i find out?
>>>>
>>>> I am using the C library coming with GNU linux distribution.
>>>
>>> That depends on the system and the library. It is probably not
>>> thread-safe.
>>
>> What brings you to that conclusion? An environment with threads but
>> without a thread safe malloc would be about as much use as a fart in
>> a wetsuit.
>
> Both are useful. For malloc, consider putting all the malloc
> (free, calloc, realloc) calls in just one thread. Don't confuse
> threads and processes, which are all OT here.

What on earth are you waffling on about now? Do you have a clue about
what you are talking about?

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!