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

[Richard]

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.

Astonishing isn't it?

 

[santosh]

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

There shouldn't be much user visible difference in a malloc
implementation for single-threaded uniprocessor system versus
single-threaded multiprocessor system. A single-threaded process can
only run on one processor at any particular instant.

 

[Kenny McCormack]

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.

One has to play to one's strengths. Don't hide your light under a bushel!

CBF is as aware of this as anyone.

 

[Kenny McCormack]

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

I'm intrigued by his comment that "Both are useful".
Obviously, his is wrong about the utility of a non-thread-safe malloc.
I would assume he is just as wrong about the utility of a fart in a
wetsuit. Doesn't surprise me, though, that he thinks it would be
useful.

 

[Antoninus Twink]

You are reacting, not thinking. Consider the effort and runtime
needed to make a malloc system thread-safe. You have to provide
something that prevents thread-changing, and something that
restores that ability.

You're talking complete bullshit. You haven't got a clue what
multithreading is, have you? There is *no way* to "prevent thread
changing". The way you protect critical sections of code and data (e.g.
malloc's list of blocks) is with a mutex - apart from the atomic
operation of asking for a mutex, you have *no control* over when the
scheduler will switch contexts.

Now you have to ensure that every malloc (etc) call is preceded by the
preventer, and followed by the restorer. Don't forget the various
error paths. This may easily slow down malloc operation by a factor
of two. Those prevent/restore calls are system calls, and expensive.
They probably need some level of privilege. Most malloc operation is
purely local.

You can replace all that garbage by a simple discipline. Only call
malloc (etc) from one thread. The results are not system dependant.

Utter nonsense. If a faster non-thread-safe malloc is available, the
implementation will use it if and only if the program isn't being linked
with a threads library.

 

[santosh]

CBFalconer wrote:

C runs on machines that concentrate on the current program at all
times

Not unless you discount all the modern general purpose systems, which
nearly all have some form of multiprocessing.

 

[Paul Hsieh]

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?

There is none at the programmer level, and there should be none
visible at the compiler library level. However, the synchronization
object that the OS uses between threads may be different. In multiple
CPUs it will typically boil down to a spin lock, in a single CPU it
will just be thread scheduler tricks. This difference *may* be
exposed to the compiler library, but it would seem inappropriate to
deal with it there.

[...] How does coordintaion with other treads affect malloc?

With respect to the comment above, it may have very different
performance characteristics. It typically impossible to make good use
of multiple CPUs if they are spin-locking a lot, so in high
performance allocators dynamic memory is typically broken into
separate pools of memory that have CPU-affinity.

 

[Eligiusz Narutowicz]

CBFalconer wrote:



Not unless you discount all the modern general purpose systems, which
nearly all have some form of multiprocessing.

I dont think he is trolling. He is right. As far as C Standard goes it is
fair to consider a single process.

 

[santosh]

I dont think he is trolling. He is right. As far as C Standard goes it
is fair to consider a single process.

That's not what he said.

 

[santosh]

That's not what he said.

Okay forget it. What he said is indeed right for uniprocessor systems,
which I suppose is the common case of most general purpose systems out
there.

 

[Eligiusz Narutowicz]

That's not what he said.

I must ask a serious question - are you trolling or trying to be stupid?

It IS what he said *BEFORE* you snipped him.

I know Mr Falconer is making a lot of mistakes from reading his posts
before, but he is right in this case. I am not sure why you are trying
to make him looking so stupid.

 

[Ian Collins]

You are reacting, not thinking. Consider the effort and runtime
needed to make a malloc system thread-safe. You have to provide
something that prevents thread-changing, and something that
restores that ability. Now you have to ensure that every malloc
(etc) call is preceded by the preventer, and followed by the
restorer. Don't forget the various error paths. This may easily
slow down malloc operation by a factor of two. Those
prevent/restore calls are system calls, and expensive. They
probably need some level of privilege. Most malloc operation is
purely local.

I suggest you spend a little time read up on thread safe allocation
schemes and come back and revisit this topic.

 

[Paul Hsieh]

You are reacting, not thinking. Consider the effort and runtime
needed to make a malloc system thread-safe. You have to provide
something that prevents thread-changing, and something that
restores that ability.

This is called a mutex. You should learn about them in any course in
operating systems or multitasking.

[...] Now you have to ensure that every malloc
(etc) call is preceded by the preventer, and followed by the
restorer. Don't forget the various error paths.

There are many classes of applications that need to be programmed
correctly. And yes, the std library is one of them. What is your
point? Its not actually even that hard to get it right.

[...] This may easily
slow down malloc operation by a factor of two.

No. A correctly implemented mutex should cost very little in the
ideal case, when there is no contention.

[...] Those
prevent/restore calls are system calls, and expensive.

You are assuming that they reach the OS every time. Look up the x86
instruction: CMPXCHG8B. Different CPUs do it differently, but
essentially boil down to that sort of functionality. You only enter
the OS to *block* when there is contention.

[...] They
probably need some level of privilege. Most malloc operation is
purely local.

WTF? You need exactly the same privileges that gave you access to the
dynamic memory in the first place.

You can replace all that garbage by a simple discipline. Only call
malloc (etc) from one thread. The results are not system
dependant.

There are certain tell tale signs of when a programmer has basically
gone to pasture. When they can no longer embrace leading edge
technologies, or understand modern concepts. They used to be called
COBOL programmers.

Every university with a decent comp sci course have augmented their
course offerings with multi-processing content. Tell these students
they can only call malloc from one of the threads and they will laugh
in your face.

 

[Ian Collins]

And I suspect you need to read some elementary texts about
concurrency.

Concurrency is part of my day to day work and has been for many, many years.

Don't forget that threads are fundamentally processes
without separate memory.

No, they are not. Some older systems may have implemented them that
way, but threads differ from processes in many ways. Ask on c.p.threads
if you want more information.

If you object to my analysis above do so, and stop mumbling.

Read Paul Hsieh's detailed response, you might learn something. He's
obviously got far more patience than me.