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

[fmassei]

On 30 Mar, 15:08, Flash Gordon <[e-mail] te:

fmas...@gmail.c om wrote, On 30/03/08 13:45:

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.programmin g.threads a better place to ask about how you can solve
your threading problems.
--
Flash Gordon

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?

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

Willem <wi****@stack.n lwrites:

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

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

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[i] = 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]

Tomás Ó hÉilidhe wrote:

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

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

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

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

[Richard]

Tomás Ó hÉilidhe <to*@lavabit.co mwrites:

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:

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.

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

[santosh]

Tomás Ó hÉilidhe wrote:

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

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?