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
17  3219 
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?
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
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.
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.
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
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
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... ?
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/
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... ?
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?
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.
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!
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
>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.
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.
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.
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Blue Ocean |
last post by:
Hey all, I have another question. I may seem like a moron here, but
where can I find out how C-standard functions like malloc() and
printf() are declared? I know that I can find on my computer...
|
by: MJL |
last post by:
I am working on a small project that involves the manipulation of
dynamically allocated memory for strings. I was wondering why the
string.h functions are the way they are and why not as follows:...
|
by: junky_fellow |
last post by:
what are reentrant functions? What are the characteristics of a reentrant code ?
what things should be kept in mind while writing a reentrant code ?
|
by: Ross A. Finlayson |
last post by:
Hi,
I hope you can help me understand the varargs facility.
Say I am programming in ISO C including stdarg.h and I declare a
function as so:
void log_printf(const char* logfilename, const...
|
by: TheOne |
last post by:
Would anyone please point me to a list of reentrant GNU C/C++ library
functions? I have searched a lot on the web for it but without any
success. Man page of signal(2) has listed system calls...
|
by: TheOne |
last post by:
Would anyone please point me to a list of reentrant C library
functions? I want to know which C library functions are safe to
use inside a signal handler across all platforms. Does GNU C
library...
|
by: Ken |
last post by:
In C programming, I want to know in what situations we should use
static memory allocation instead of dynamic memory allocation. My
understanding is that static memory allocation like using array...
|
by: Peterwkc |
last post by:
Hello all expert, i have two program which make me desperate bu after i have noticed the forum, my future is become brightness back.
By the way, my problem is like this i the first program was...
|
by: Bit Byte |
last post by:
I am modifying some legacy code, to make the functions reentrant. I use
lots of global data (large nested structs) to pass data around quicky.
The global structures are far too large (in size) for...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
