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

[Morris Dovey]

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/

[fmassei]

On 30 Mar, 20:50, santosh <santosh....@gm ail.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.

[fmassei]

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.programmin g.threads for any
further questions? Please?

Sure! And thank you very much for the help!

[lawrence.jones]

Tom?s ? h?ilidhe <to*@lavabit.co mwrote:

>
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

[Gordon Burditt]

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

[Anonymous]

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.

[christian.bau]

On Apr 3, 2:45*am, Anonymous <[e-mail] :

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.

[Anonymous]

On Thu, 03 Apr 2008 15:38:37 -0700, christian.bau wrote:

On Apr 3, 2:45Â*am, Anonymous <[e-mail] :

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