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?

 
 
Eligiusz Narutowicz
Guest
Posts: n/a
 
      04-27-2008
santosh <(E-Mail Removed)> writes:

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


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.


 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      04-27-2008
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.
 
Reply With Quote
 
 
 
 
Paul Hsieh
Guest
Posts: n/a
 
      04-27-2008
On Apr 27, 8:59 am, CBFalconer <(E-Mail Removed)> 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.


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