Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Is malloc() function provided in <stdlib.h> thread-safe?

Reply
Thread Tools

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

 
 
Richard
Guest
Posts: n/a
 
      04-27-2008
Antoninus Twink <(E-Mail Removed)> writes:

> 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?
 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      04-27-2008
Øyvind Røtvold wrote:

> CBFalconer <(E-Mail Removed)> writes:
>
>> Ø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.

 
Reply With Quote
 
 
 
 
Kenny McCormack
Guest
Posts: n/a
 
      04-27-2008
In article <(E-Mail Removed)>,
Antoninus Twink <(E-Mail Removed)> wrote:
>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.

 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      04-27-2008
In article <fv1b8k$e9f$(E-Mail Removed)>,
Richard <(E-Mail Removed)> 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. 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.

 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      04-27-2008
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.

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      04-27-2008
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.

 
Reply With Quote
 
Paul Hsieh
Guest
Posts: n/a
 
      04-27-2008
On Apr 26, 11:18 am, Øyvind Røtvold <(E-Mail Removed)> wrote:
> "Herbert Rosenau" <(E-Mail Removed)> 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?


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/
 
Reply With Quote
 
Eligiusz Narutowicz
Guest
Posts: n/a
 
      04-27-2008
santosh <(E-Mail Removed)> writes:

> 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.
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      04-27-2008
Eligiusz Narutowicz wrote:

> santosh <(E-Mail Removed)> writes:
>
>> 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.

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      04-27-2008
santosh wrote:

> Eligiusz Narutowicz wrote:
>
>> santosh <(E-Mail Removed)> writes:
>>
>>> 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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how to call a C++ function from a C file when provided with only compiled code ankitjain.bvcoe@gmail.com C++ 1 09-15-2006 05:24 AM
Using Tracing provided by Logging and Instrrumentation Appln block in Web Application Samy ASP .Net 0 11-10-2005 08:31 PM
Ensuring users have provided valid html Peter Hardy ASP .Net 0 12-29-2004 08:36 AM
problem related to the sort function provided by STL Rachel Forder C++ 2 10-12-2003 10:16 PM
Re: DOT NET frame work provided session management using SQL SERVER MS News \(MS ILM\) ASP .Net 0 08-26-2003 12:56 AM



Advertisments