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

In article <b8**********************************@27g2000hsf.g ooglegroups.com>,
<cl*********@gmail.comwrote:

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

cl*********@gmail.com 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.

--
Ian Collins.

In comp.lang.c, cl*********@gmail.com 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?

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

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

On Apr 25, 1:12 pm, climber....@gmail.com 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.

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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

On Fri, 25 Apr 2008 20:12:46 UTC, cl*********@gmail.com 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.

--
Tschau/Bye
Herbert

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

Paul Hsieh wrote:

climber....@gmail.com wrote:

>Does anyone have experience on the thread-safty issue with malloc()?

.... snip ...

>

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

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

cl*********@gmail.com 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. It probably is process-safe, because a different
process normally has a different memory map. Neither is covered in
the C standard, so this does not affect C standard compatibility.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

On 25 Apr 2008 at 22:33, CBFalconer wrote:

Paul Hsieh wrote:

>climber....@gmail.com 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 <no****@nospam.invalidwrites:

On 25 Apr 2008 at 22:33, CBFalconer wrote:

>Paul Hsieh wrote:

>>climber....@gmail.com 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".

"Herbert Rosenau" <os****@pc-rosenau.dewrites:

[ ... ]

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?
--
... __o Øyvind
... _`\(, http://www.darkside.no/olr/
... (_)/(_) ... biciclare necesse est ...

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>>climber....@gmail.com 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

On Apr 26, 2:18 pm, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson)
wrote:

In article <slrng16mtk.5i9.nos...@nospam.invalid>,
Antoninus Twink <nos...@nospam.invalidwrote:

>climber....@gmail.com 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?

Yevgen

CBFalconer wrote:

cl*********@gmail.com 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.

--
Ian Collins.

Ian Collins wrote:

CBFalconer wrote:

>cl*********@gmail.com 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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

Walter Roberson wrote:

>

.... snip ...

>
The original poster asked a general question about thread-safety
in malloc(), not one restricted to systems with threads
implementations.

But, if the system doesn't have a thread implementation, then the
question is purposeless. Without threads, malloc is thread-safe.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

Øyvind Røtvold wrote:

>

.... snip ...

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

The malloc system (includes free, realloc, calloc) must keep track
of the memory it controls, or doesn't control. This means updating
some dedicated memory somewhere. If multiple threads can access
that memory at any time things can get way out of whack. Consider
just the problem of counting malloced blocks.

n = blockcount;
if (n < MAX) {
n++;
p := execmalloc(sz); /* altering other values */
}
blockcount = n;

and see what happens if that sequence is interrupted after any
statement, and another thread executes the same code.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

CBFalconer wrote:

Ian Collins wrote:

>CBFalconer wrote:

>>cl*********@gmail.com 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.

--
Ian Collins.

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? I maintain that having the
malloc system available is useful.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

On Sat, 26 Apr 2008 18:18:06 UTC, Øyvind Røtvold <or******@gmail.com>
wrote:

>
"Herbert Rosenau" <os****@pc-rosenau.dewrites:

[ ... ]

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!

CBFalconer <cb********@yahoo.comwrites:

Øyvind Røtvold wrote:

>>

... snip ...

>>
Just curious here, what's the difference between these two? How
does coordintaion with other treads affect 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 :-/.

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

--
... __o Øyvind
... _`\(, http://www.darkside.no/olr/
... (_)/(_) ... biciclare necesse est ...

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 <or******@gmail.comwrites:

"Herbert Rosenau" <os****@pc-rosenau.dewrites:

[ ... ]

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

--
... __o Øyvind
... _`\(, http://www.darkside.no/olr/
... (_)/(_) ... biciclare necesse est ...

"Herbert Rosenau" <os****@pc-rosenau.dewrites:

On Sat, 26 Apr 2008 18:18:06 UTC, Øyvind Røtvold <or******@gmail.com>
wrote:

>>
"Herbert Rosenau" <os****@pc-rosenau.dewrites:

[ ... ]

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.

--
... __o Øyvind
... _`\(, http://www.darkside.no/olr/
... (_)/(_) ... biciclare necesse est ...

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.

--
Ian Collins.

CBFalconer <cb********@yahoo.comwrites:

Ian Collins wrote:

>CBFalconer wrote:

>>cl*********@gmail.com 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?

Antoninus Twink <no****@nospam.invalidwrites:

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.

Astonishing isn't it?

Øyvind Røtvold wrote:

CBFalconer <cb********@yahoo.comwrites:

>Øyvind Røtvold wrote:

>>>

... snip ...

>>>
Just curious here, what's the difference between these two? How
does coordintaion with other treads affect 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 :-/.

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.

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

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

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

CBF is as aware of this as anyone.

In article <fv**********@registered.motzarella.org>,
Richard <de***@gmail.comwrote:
....

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

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.

Ian Collins wrote:

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.

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.

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

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

Øyvind Røtvold wrote:

CBFalconer <cb********@yahoo.comwrites:

>Øyvind Røtvold wrote:

>>>

... snip ...

>>>
Just curious here, what's the difference between these two? How
does coordintaion with other treads affect 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 :-/.

Processes are a different matter, because a different process
normally has a different memory space, and malloc for a process
runs in that processes memory space. This thread has been
discussing threads (two different uses for the same word :-)

This is all OT for c.l.c. The standard never mentions threads nor
processes. C runs on machines that concentrate on the current
program at all times :-)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

On 27 Apr 2008 at 15:59, CBFalconer wrote:

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.

CBFalconer wrote:

<snip>

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.

On Apr 26, 11:18 am, Øyvind Røtvold <orotv...@gmail.comwrote:

"Herbert Rosenau" <os2...@pc-rosenau.dewrites:
[ ... ]

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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

santosh <sa*********@gmail.comwrites:

CBFalconer wrote:

<snip>

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

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

Eligiusz Narutowicz wrote:

santosh <sa*********@gmail.comwrites:

>CBFalconer wrote:

<snip>

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

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 wrote:

Eligiusz Narutowicz wrote:

>santosh <sa*********@gmail.comwrites:

>>CBFalconer wrote:

<snip>

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.

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.

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.

santosh <sa*********@gmail.comwrites:

Eligiusz Narutowicz wrote:

>santosh <sa*********@gmail.comwrites:

>>CBFalconer wrote:

<snip>

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.

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.

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.

CBFalconer wrote:

Ian Collins wrote:

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

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.

--
Ian Collins.

On Apr 27, 8:59 am, CBFalconer <cbfalco...@yahoo.comwrote:

Ian Collins wrote:

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.

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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Ian Collins wrote:

CBFalconer wrote:

.... snip ...

>

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

And I suspect you need to read some elementary texts about
concurrency. Don't forget that threads are fundamentally processes
without separate memory. If you object to my analysis above do so,
and stop mumbling.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

santosh wrote:

CBFalconer wrote:

<snip>

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

You can throw in the word 'apparently' in the appropriate place.
The purpose of systems is, among other things, to implement all
those improvements without affecting the programmers thinking.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

santosh wrote:

Eligiusz Narutowicz wrote:

>santosh <sa*********@gmail.comwrites:

>>CBFalconer wrote:

<snip>

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.

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.

Yes it is. C is defined by the C standard.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

** Posted from http://www.teranews.com **

CBFalconer wrote:

Ian Collins wrote:

>CBFalconer wrote:

.... snip ...

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

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.

--
Ian Collins.