Reentrant functions and memory allocation

[fmassei]

Dear all,
I'm trying to put some old code in a portable, cross-platform library
and I'm facing a big problem: is there a standard, platform-
independent way to write a reentrant function that allocate dynamic
memory? In other words: is it safe to use malloc() or free() in a
thread-safe function?
Thank you,
Francesco

 

[Flash Gordon]

Dear all,
I'm trying to put some old code in a portable, cross-platform library
and I'm facing a big problem: is there a standard, platform-
independent way to write a reentrant function that allocate dynamic
memory? In other words: is it safe to use malloc() or free() in a
thread-safe function?

Re-entrancy and thread safety are not the same. The C standard does not
know about threads but does know a little about reentrancy, and
malloc/realloc/free are not required to be reentrant. You might find
comp.programming.threads a better place to ask about how you can solve
your threading problems.

 

[santosh]

Dear all,
I'm trying to put some old code in a portable, cross-platform library
and I'm facing a big problem: is there a standard, platform-
independent way to write a reentrant function that allocate dynamic
memory? In other words: is it safe to use malloc() or free() in a
thread-safe function?
Thank you,
Francesco

I think most malloc implementations are reentrant. All you need to do is
to ensure that your data objects are also thread safe, which means
using as few static objects as possible.

 

[Eric Sosman]

Dear all,
I'm trying to put some old code in a portable, cross-platform library
and I'm facing a big problem: is there a standard, platform-
independent way to write a reentrant function that allocate dynamic
memory? In other words: is it safe to use malloc() or free() in a
thread-safe function?

The answer to your first question is "Yes: use malloc()
and free()."

<off-topic>

The answer to your second question is "No." A re-entrant
function is not necessarily thread-safe.

If you are dealing with a thread problem, you'll probably
get much better answers on comp.programming.threads than you
will here. The C language itself has no support for multi-
threading, and only the faintest notion that such a thing
might even exist.

</off-topic>

 

[CBFalconer]

I'm trying to put some old code in a portable, cross-platform
library and I'm facing a big problem: is there a standard,
platform-independent way to write a reentrant function that
allocate dynamic memory? In other words: is it safe to use
malloc() or free() in a thread-safe function?

No. Because the malloc system will be operating on it's own memory
areas, and is not re-entrant. You have to ensure that all accesses
to the malloc package are done through appropriate guards.

 

[fmassei]

(e-mail address removed) wrote, On 30/03/08 13:45:


Re-entrancy and thread safety are not the same. The C standard does not
know about threads but does know a little about reentrancy, and
malloc/realloc/free are not required to be reentrant. You might find
comp.programming.threads a better place to ask about how you can solve
your threading problems.

This is what I was worried about. I just want to write something that
can be safely used in a multi-threaded project, if someone wants to.
Should I consider to work only with pre-allocated memory? Doing this
way the problem can be moved outside the library. Is this the only
solution I have?

 

[Morris Dovey]

This is what I was worried about. I just want to write something that
can be safely used in a multi-threaded project, if someone wants to.
Should I consider to work only with pre-allocated memory? Doing this
way the problem can be moved outside the library. Is this the only
solution I have?

You're invited to take a look at

http://www.iedu.com/mrd/c/getsm.c

 

[Eric Sosman]

No. Because the malloc system will be operating on it's own memory
areas, and is not re-entrant. You have to ensure that all accesses
to the malloc package are done through appropriate guards.

<off-topic>

For POSIX threads, malloc() et al. already contain whatever
guards are required, and you need provide no further protection
when calling them.

It's because of answers of this kind -- sort of right but
mostly not -- that it's been suggested you seek advice not here,
but on a forum where threading experts hang out.

</off-topic>

 

[Richard]

<off-topic>

For POSIX threads, malloc() et al. already contain whatever
guards are required, and you need provide no further protection
when calling them.

It's because of answers of this kind -- sort of right but
mostly not -- that it's been suggested you seek advice not here,
but on a forum where threading experts hang out.

</off-topic>

There are still people like Chuck there spouting nonsense. If you dont
know, dont answer.

 

[Willem]

Richard wrote:
) There are still people like Chuck there spouting nonsense. If you dont
) know, dont answer.

And if you *do* know where correct answers can be found ? Exactly.

If you want to ask about threads, go to comp.programming.threads


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Richard]

Richard wrote:
) There are still people like Chuck there spouting nonsense. If you dont
) know, dont answer.

And if you *do* know where correct answers can be found ? Exactly.

If you want to ask about threads, go to comp.programming.threads

And you are? If I feel I have a question I wish to address to a large
bunch of theoretically helpful (they are here after all) and
knowledgeable C programmers I will ask it here. If you do not wish to
answer then feel free to ignore it.

 

[fmassei]

Richard wrote:

) There are still people like Chuck there spouting nonsense. If you dont
) know, dont answer.

And if you *do* know where correct answers can be found ? Exactly.

If you want to ask about threads, go to comp.programming.threads

Thank you all for the advice, I will write another post there. Anyway,
AFAIK any reentrant function is thread-safe. So, as long as I keep my
library functions reentrant there are no problems. Unfortunately there
are no standard c functions to allocate dynamic memory that are
assured to be reentrant. Is everything correct?

 

[Tomás Ó hÉilidhe]

Why are people talking about malloc being or not being re-entrant? We
don't see the definition of malloc, so we don't care if it calls
itself internally.

As for malloc being called from within a re-entrant function, then I
see no problem:

void Func(unsigned const i)
{
static char *addresses[4];

addresses = malloc(1);

if (3 == i) return;

Func(i+1);
}

int main(void)
{
Func(0);

return 0;
}

As for malloc being thread-safe, then I think the bottom line is that
the C standard doesn't guarantee that malloc is thread-safe. All is
not lost though, all you need to do is find a thread-safe
implementation of malloc... you don't have to edit all the old code.

 

[Willem]

Richard wrote:
) And you are? If I feel I have a question I wish to address to a large
) bunch of theoretically helpful (they are here after all) and
) knowledgeable C programmers I will ask it here. If you do not wish to
) answer then feel free to ignore it.

Unlike you, most people who come here with questions about something
indirectly related to C, such as threads for example, do not do this
with the specific intention of getting answers from knowledgeable
C programmers. They want answers from people knowledgeable about the
subject they are asking about, so the polite thing to do is to direct
them to where such people are most likely to be found.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[CBFalconer]

Why are people talking about malloc being or not being re-entrant?
We don't see the definition of malloc, so we don't care if it
calls itself internally.

As for malloc being called from within a re-entrant function,
then I see no problem:

Because, (and this is OT) while a malloc call is executing, an
interrupt may occur (including OS time-outs) and another process or
thread execute. This may call malloc with the underlying
structures in a dangerous condition.

Note that processes usually have unique memory areas, so that the
malloc memory is isolated. This does not apply to threads.

 

[Tomás Ó hÉilidhe]

CBFalconer:

Because, (and this is OT) while a malloc call is executing, an
interrupt may occur (including OS time-outs) and another process or
thread execute. This may call malloc with the underlying
structures in a dangerous condition.

Note that processes usually have unique memory areas, so that the
malloc memory is isolated. This does not apply to threads.

I still don't understand. Here's what I think I understand:

1) If a function is thread-safe, then it can be executed more than
once simultaneously without malfunctioning. In general, to make a
function thread-safe, you avoid using static-duration objects and
instead opt for using automatic-duration objects.
2) If a function is re-entrant, then it can execute itself without
malfunctioning.

If you have a multi-threaded program that uses malloc, then I can
definitely understand why you'd want malloc to be thread-safe. But I
fail to understand why you'd want it to be re-entrant.

If you wanted malloc to be re-entrant, then that suggests to me that
you want to be able to call malloc from within malloc... which sounds
ridiculous to me because you shouldn't be going near the definition of
malloc.

I'm not saying I'm right or wrong, but I do know that I don't fully
understand. So could someone please explain why we'd want malloc to be
re-entrant... ?

 

[Morris Dovey]

If you wanted malloc to be re-entrant, then that suggests to me that
you want to be able to call malloc from within malloc... which sounds
ridiculous to me because you shouldn't be going near the definition of
malloc.

I'm not saying I'm right or wrong, but I do know that I don't fully
understand. So could someone please explain why we'd want malloc to be
re-entrant... ?

Re-entrancy means that a function can be called again even before
current/previous invocations have been completed. The
(additional) invocations by different tasks aren't the same as
recursive invocations from within the function in question.

 

[Richard]

CBFalconer:



I still don't understand. Here's what I think I understand:

You dont understand because Falconer is making a mess again.

He wants to talk about "standard malloc" but at the same time talk about
non standard re-entrance.

 

[santosh]

CBFalconer:



I still don't understand. Here's what I think I understand:

1) If a function is thread-safe, then it can be executed more than
once simultaneously without malfunctioning. In general, to make a
function thread-safe, you avoid using static-duration objects and
instead opt for using automatic-duration objects.
2) If a function is re-entrant, then it can execute itself without
malfunctioning.

If you have a multi-threaded program that uses malloc, then I can
definitely understand why you'd want malloc to be thread-safe. But I
fail to understand why you'd want it to be re-entrant.

If you wanted malloc to be re-entrant, then that suggests to me that
you want to be able to call malloc from within malloc... which sounds
ridiculous to me because you shouldn't be going near the definition of
malloc.

I'm not saying I'm right or wrong, but I do know that I don't fully
understand. So could someone please explain why we'd want malloc to be
re-entrant... ?

What if during a call to malloc() from thread A, the system suspends the
thread and schedules thread B which calls malloc()? Shouldn't malloc()
be reentrant to function properly in this scenario?

 

[fmassei]

What if during a call to malloc() from thread A, the system suspends the
thread and schedules thread B which calls malloc()? Shouldn't malloc()
be reentrant to function properly in this scenario?

For what I know, one of the rules to make a function reentrant is to
call only reentrant functions (obviously). This is the reason to know
if malloc() is or not reentrant.