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

Discussion in 'C Programming' started by climber.cui@gmail.com, Apr 25, 2008.

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

    thanks a lot.

    tony
     
    , Apr 25, 2008
    #1
    1. Advertising

  2. 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
     
    Walter Roberson, Apr 25, 2008
    #2
    1. Advertising

  3. Ian Collins Guest

    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.
     
    Ian Collins, Apr 25, 2008
    #3
  4. Lew Pitcher Guest

    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?


    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. ------
     
    Lew Pitcher, Apr 25, 2008
    #4
  5. Paul Hsieh Guest

    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.


    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/
     
    Paul Hsieh, Apr 25, 2008
    #5
  6. 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.

    --
    Tschau/Bye
    Herbert

    Visit http://www.ecomstation.de the home of german eComStation
    eComStation 1.2R Deutsch ist da!
     
    Herbert Rosenau, Apr 26, 2008
    #6
  7. 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, Apr 26, 2008
    #7
  8. Richard Guest

    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".
     
    Richard, Apr 26, 2008
    #8
  9. "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?


    --
    ... __o Øyvind
    ... _`\(, http://www.darkside.no/olr/
    ... (_)/(_) ... biciclare necesse est ...
     
    Øyvind Røtvold, Apr 26, 2008
    #9
  10. 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
     
    Walter Roberson, Apr 26, 2008
    #10
  11. 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?

    Yevgen
     
    , Apr 26, 2008
    #11
  12. Ian Collins Guest

    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.

    --
    Ian Collins.
     
    Ian Collins, Apr 26, 2008
    #12
  13. Ian Collins Guest

    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.

    --
    Ian Collins.
     
    Ian Collins, Apr 27, 2008
    #13
  14. 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.



    --
    Tschau/Bye
    Herbert

    Visit http://www.ecomstation.de the home of german eComStation
    eComStation 1.2R Deutsch ist da!
     
    Herbert Rosenau, Apr 27, 2008
    #14
  15. CBFalconer <> 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 :-/.

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

    --
    ... __o Øyvind
    ... _`\(, http://www.darkside.no/olr/
    ... (_)/(_) ... biciclare necesse est ...
     
    Øyvind Røtvold, Apr 27, 2008
    #15
  16. 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.
     
    Antoninus Twink, Apr 27, 2008
    #16
  17. Ø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:

    How does coordination with other apps affect malloc optimisations?

    --
    ... __o Øyvind
    ... _`\(, http://www.darkside.no/olr/
    ... (_)/(_) ... biciclare necesse est ...
     
    Øyvind Røtvold, Apr 27, 2008
    #17
  18. "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.

    --
    ... __o Øyvind
    ... _`\(, http://www.darkside.no/olr/
    ... (_)/(_) ... biciclare necesse est ...
     
    Øyvind Røtvold, Apr 27, 2008
    #18
  19. Ian Collins Guest

    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.
     
    Ian Collins, Apr 27, 2008
    #19
  20. Richard Guest

    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?
     
    Richard, Apr 27, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anton Dec

    malloc without stdlib.h

    Anton Dec, Jun 5, 2007, in forum: C Programming
    Replies:
    19
    Views:
    1,427
  2. Nehil

    is malloc thread-safe??

    Nehil, Jul 21, 2007, in forum: C Programming
    Replies:
    39
    Views:
    1,585
    Chris Thomasson
    Aug 9, 2007
  3. Gabriel Rossetti
    Replies:
    0
    Views:
    1,332
    Gabriel Rossetti
    Aug 29, 2008
  4. mangesh sawant
    Replies:
    2
    Views:
    1,896
    Andy Venikov
    Feb 13, 2011
  5. John Nagle
    Replies:
    5
    Views:
    475
    John Nagle
    Mar 12, 2012
Loading...

Share This Page