468,249 Members | 1,461 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,249 developers. It's quick & easy.

Reentrant functions and memory allocation

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
Mar 30 '08 #1
17 2775
On 30 Mar, 15:08, Flash Gordon <s...@flash-gordon.me.ukwrote:
fmas...@gmail.com 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.programming.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?
Mar 30 '08 #2
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
Mar 30 '08 #3
Willem <wi****@stack.nlwrites:
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.
Mar 30 '08 #4

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.
Mar 30 '08 #5
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
Mar 30 '08 #6
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

Mar 30 '08 #7
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... ?
Mar 30 '08 #8
Tomás Ó hÉilidhe wrote:
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.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto/
Mar 30 '08 #9
Tomás Ó hÉilidhe <to*@lavabit.comwrites:
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... ?
Mar 30 '08 #10
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?

Mar 30 '08 #11
On 30 Mar, 20:50, santosh <santosh....@gmail.comwrote:
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?
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.
Mar 30 '08 #12
No. 7.1.4p4:
>
"The functions in the standard library are not
guaranteed to be reentrant and may modify objects
with static storage duration.158)

158) Thus, a signal handler cannot, in general,
call standard library functions."

Now, will you please go to comp.programming.threads for any
further questions? Please?
Sure! And thank you very much for the help!
Mar 30 '08 #13
Tom?s ? h?ilidhe <to*@lavabit.comwrote:
>
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.
A function calling itself is recursion, not reentrancy.

Reentrancy means that multiple independent invocations of the function
can be executing concurrently. In the context of standard C, the only
way to have multiple concurrent invocations of a function is via signal
handlers, so the C Standard's statement that library functions aren't
reentrant means that you can't call any library function from a signal
handler that could possible be invoked while that library function is
running from a call in the mainline code.

Thread safety is a bit weaker than reentrancy since a non-reentrant
function can be made thread safe by adding synchronization primitives
that stop all but one thread from executing at a time.

-Larry Jones

We don't ATTEND parties, we just CRASH 'em. -- Calvin
Mar 30 '08 #14
>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.
*FROM A DIFFERENT THREAD*. Think about calling malloc() from a signal
handler entered when the thread is already in malloc().
>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.
One definition of re-entrant (taken from Wikipedia, along with some
old OS/360 manuals from the 1970's that talked about "reentrant"
vs. "serially-reusable" code modules) says that it must not rely
on locks to singleton resources, and it must not call non-reentrant
routines.

Now, if multiple threads allocate out of the same pool of memory, then
malloc() must use locking, and that makes it non-reentrant. It also
makes anything that calls malloc() non-reentrant. (could still be
thread-safe, though).
>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.
Think about malloc() called from a signal handler. Especially in
a single-threaded program.
>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.
But you might be in the middle of malloc() in your thread when, say,
SIGCHLD or SIGINT goes off, and your signal handler wants to allocate
memory to log the event (and perhaps tell the thread to do something
about it).
>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... ?
signals.
Mar 31 '08 #15
On Tue, 01 Apr 2008 23:08:27 +0200, Antoninus Twink wrote:
I think there might some weird corner-cases of
reentrant-but-not-threadsafe functions (the language lawyers here will
surely know), but basically, yes, if it's reentrant then it's going to
be threadsafe.
Not quite accurate. It'd be better to say that if it's reentrant, it's
possible to use it in a thread-safe manner.

An example of a function that's reentrant but not threadsafe:

void foo(int *i)
{
(*i)++;
}

This function is reentrant, as it can concurrently be called, and no
2 calls can interfere with each other. However, it's not entirely thread
safe, as 2 calls with the same data will produce a race condition. To
make this function fully threadsafe, you'd need some form of lock around
the access to *i

nb: I've seen reentrant used in a few different senses across the
intarwebs, this one seems to be most common. Other senses could even end
up meaning "both thread and deadlock safe", "threadsafe and lockfree",
and a variety of others meanings.
Apr 3 '08 #16
On Apr 3, 2:45*am, Anonymous <no-respo...@no-server.comwrote:
An example of a function that's reentrant but not threadsafe:

void foo(int *i)
{
* * (*i)++;

}

This function is reentrant, as it can concurrently be called, and no
2 calls can interfere with each other.
It is not reentrant. If I have a static variable int x; and I call foo
(&x); and in the middle of the call a signal is raised and the signal
handler calls foo (&x), then you don't know whether x is increased by
2, by 1, or whether you get a result that is just rubbish.
Apr 3 '08 #17
On Thu, 03 Apr 2008 15:38:37 -0700, christian.bau wrote:
On Apr 3, 2:45Â*am, Anonymous <no-respo...@no-server.comwrote:
>An example of a function that's reentrant but not threadsafe:

void foo(int *i)
{
Â* Â* (*i)++;

}

This function is reentrant, as it can concurrently be called, and no 2
calls can interfere with each other.

It is not reentrant. If I have a static variable int x; and I call foo
(&x); and in the middle of the call a signal is raised and the signal
handler calls foo (&x), then you don't know whether x is increased by 2,
by 1, or whether you get a result that is just rubbish.
That's what I said, and why I had the epilogue at the end of my post
about the varying definitions of reentrant. The one I was using, and have
seen used most often, is that *when called on independent data* the
reentrant function is thread safe. If you'd read the line just after you
snipped, you would have seen this.
Jun 27 '08 #18

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

14 posts views Thread by Blue Ocean | last post: by
6 posts views Thread by junky_fellow | last post: by
2 posts views Thread by TheOne | last post: by
9 posts views Thread by TheOne | last post: by
12 posts views Thread by Bit Byte | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by kermitthefrogpy | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.