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

[climber.cui]

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.

thanks a lot.

tony

 

[Walter Roberson]

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.

 

[Ian Collins]

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.

 

[Lew Pitcher]

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?

Read your compiler's documentation. Read the documentation on your runtime.

I am using the C library coming with GNU linux distribution.

<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.

thanks a lot.

tony

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Paul Hsieh]

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.

Some compilers come with thread-safe versus non-thread-safe standard
libraries. Check your documentation.

[...] Is it possible this
function evolves from thread-unsafe to thread-safe in recent years?

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.

Certainly gcc is thread-safe.

 

[Herbert Rosenau]

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.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Antoninus Twink]

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?

 

[Richard]

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".

 

[Øyvind Røtvold]

[ ... ]

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?

 

[Walter Roberson]

*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.

 

[ymuntyan]

*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.[/QUOTE]

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?

Yevgen

 

[Ian Collins]

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.

 

[Ian Collins]

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.

 

[Herbert Rosenau]

[ ... ]

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.



--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Øyvind Røtvold]

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 :-/.

[ snip answer to question as written but not as intended. ]

 

[Antoninus Twink]

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]

[ ... ]

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:

How does coordination with other apps affect malloc optimisations?

 

[Øyvind Røtvold]

[ ... ]

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.

 

[Ian Collins]

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.

 

[Richard]

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?