re-entrant function????????

[thesushant@rediffmail.com]

hi,

can anyone of C masters siting out there suggest any 1 example of
re-entrnt function just to show what is the significance of that
property and how we can exploit it ....

sushant

[Yan]

Re: re-entrant function??????? ?

thesushant@redi ffmail.com wrote:[color=blue]
> hi,
>
> can anyone of C masters siting out there suggest any 1 example of
> re-entrnt function just to show what is the significance of that
> property and how we can exploit it ....
>
> sushant
>[/color]

that becomes an issue when using/writing multi-threading code. If a
function relies on static data, and is called while another thread has
already called it and is executing, that static data may be changed by
different threads and produce unexpected results

[CBFalconer]

Re: re-entrant function??????? ?

thesushant@redi ffmail.com wrote:[color=blue]
>
> can anyone of C masters siting out there suggest any 1 example of
> re-entrnt function just to show what is the significance of that
> property and how we can exploit it ....[/color]

#include <stdio.h>

int putword(unsigne d long w, FILE *f)
{
if (w > 9)
if (0 > putword(w / 10, f)) return EOF;
return putc((w % 10) + '0', f);
} /* putword */

/* --------------- */

#ifdef TESTING

#include <stdlib.h>

int main(void)
{
int i;

for (i = 0; i < 10; i++) {
putword(i, stdout);
putc(' ', stdout);
putword(rand(), stdout);
putc('\n', stdout);
}
return 0;
} /* main */
#endif


--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Trent Buck]

Re: re-entrant function??????? ?

Up spake thesushant@redi ffmail.com:[color=blue]
> can anyone of C masters siting out there suggest any 1 example of
> re-entrnt function just to show what is the significance of that
> property and how we can exploit it ....[/color]

This is re-entrant

int
f (int x)
{
int y;

y = x * x;
return y;
}

This is not

int y;

int
f (int x)
{
y = x * x;
return y;
}

Another example of re-entrant vs. non-reentrant functions is strtok_r
vs. strtok.

As the OP said, it becomes an issue when you have multiple threads
(lightweight processes) in a single process, because (some) state is
shared between multiple threads of execution.

The canonical example is

int x;
void f (void) { x++; }

with two threads executing f(). The ++ operation (typically) resolves
into three assembly instructions: copy-memory-to-register,
increment-register, and copy-register-to-memory.

Consider, for example, the situation where first thread executes the
first two instructions, then the second thread executes all three, then
the first thread executes the last instruction. The second thread's
change will be lost, and the contents of memory at that address will be
incorrect.

This class of bugs are a PITA to locate, because symptoms are
intermittent and therefore difficult to reproduce.

--
-trent
How, Joe wondered, can a man have courage without faith, without belief?
Burroughs believed in nothing, and yet there he sat stubborn as Luther.

[pete]

Re: re-entrant function??????? ?

CBFalconer wrote:[color=blue]
>
> thesushant@redi ffmail.com wrote:[color=green]
> >
> > can anyone of C masters siting out there suggest any 1 example of
> > re-entrnt function just to show what is the significance of that
> > property and how we can exploit it ....[/color]
>
> #include <stdio.h>
>
> int putword(unsigne d long w, FILE *f)
> {
> if (w > 9)
> if (0 > putword(w / 10, f)) return EOF;
> return putc((w % 10) + '0', f);
> } /* putword */[/color]

Standard library functions aren't guaranteed to be reentrant, so,
a function which calls putc can't be guaranteed to be reentrant.

--
pete

[Thomas Stegen]

Re: re-entrant function??????? ?

pete wrote:[color=blue]
> CBFalconer wrote:
>[color=green]
>>thesushant@re diffmail.com wrote:
>>[color=darkred]
>>>can anyone of C masters siting out there suggest any 1 example of
>>>re-entrnt function just to show what is the significance of that
>>>property and how we can exploit it ....[/color]
>>
>>#include <stdio.h>
>>
>>int putword(unsigne d long w, FILE *f)
>>{
>> if (w > 9)
>> if (0 > putword(w / 10, f)) return EOF;
>> return putc((w % 10) + '0', f);
>>} /* putword */[/color]
>
>
> Standard library functions aren't guaranteed to be reentrant, so,
> a function which calls putc can't be guaranteed to be reentrant.
>[/color]

More importantly imo is that putc has a side effect on the file and so
the function is not reentrant even on an implementation where putc is
reentrant.

--
Thomas.

[dandelion]

Re: re-entrant function??????? ?


"Trent Buck" <geragohpx@tznv y.pbz> wrote in message
news:2005011117 0803.4392df8d@h arpo.marx...
<snip>
[color=blue]
> As the OP said, it becomes an issue when you have multiple threads
> (lightweight processes) in a single process, because (some) state is
> shared between multiple threads of execution.[/color]
<snip>

Minor nitpick:

Reentrancy is not just a multi-threading (lightweight processes) issue, but
arises whenever two threads of execution have access to some common
function. Apart from the example given, this may also happen in Interrupt
Service Routines (ISR's) or multitasking environments wich allow concurrent
access to a shared resource.

[Eltee]

Re: re-entrant function??????? ?

dandelion wrote:[color=blue]
> "Trent Buck" <geragohpx@tznv y.pbz> wrote in message
> news:2005011117 0803.4392df8d@h arpo.marx...
> <snip>
>[color=green]
>>As the OP said, it becomes an issue when you have multiple threads
>>(lightweigh t processes) in a single process, because (some) state is
>>shared between multiple threads of execution.[/color]
>
> <snip>
>
> Minor nitpick:
>
> Reentrancy is not just a multi-threading (lightweight processes) issue, but
> arises whenever two threads of execution have access to some common
> function. Apart from the example given, this may also happen in Interrupt
> Service Routines (ISR's) or multitasking environments wich allow concurrent
> access to a shared resource.[/color]

Pardon me but ... are reentrancy, multi-threading, ISR's and multitasking really
a part of ISO C specification?

[dandelion]

Re: re-entrant function??????? ?


"Eltee" <eltee@hotmail. com> wrote in message
news:34htveF4a8 v37U1@individua l.net...[color=blue]
> dandelion wrote:[color=green]
> > "Trent Buck" <geragohpx@tznv y.pbz> wrote in message
> > news:2005011117 0803.4392df8d@h arpo.marx...
> > <snip>
> >[color=darkred]
> >>As the OP said, it becomes an issue when you have multiple threads
> >>(lightweigh t processes) in a single process, because (some) state is
> >>shared between multiple threads of execution.[/color]
> >
> > <snip>
> >
> > Minor nitpick:
> >
> > Reentrancy is not just a multi-threading (lightweight processes) issue,[/color][/color]
but[color=blue][color=green]
> > arises whenever two threads of execution have access to some common
> > function. Apart from the example given, this may also happen in[/color][/color]
Interrupt[color=blue][color=green]
> > Service Routines (ISR's) or multitasking environments wich allow[/color][/color]
concurrent[color=blue][color=green]
> > access to a shared resource.[/color]
>
> Pardon me but ... are reentrancy, multi-threading, ISR's and multitasking[/color]
really[color=blue]
> a part of ISO C specification?[/color]

Reentrancy is, for the simple reason that the standard lib is not guaranteed
to be reentrant (and that is, IIRC, part of the standard). A further
discussion of "reentrancy " brings on the other subjects.

So while not being part of the standard, they (multithreading , ISR's and
shared resources) are topical in this limited treatment.

[Eltee]

Re: re-entrant function??????? ?

dandelion wrote:[color=blue]
> "Eltee" <eltee@hotmail. com> wrote in message
> news:34htveF4a8 v37U1@individua l.net...
>[color=green]
>>dandelion wrote:
>>[color=darkred]
>>>"Trent Buck" <geragohpx@tznv y.pbz> wrote in message
>>>news:2005011 1170803.4392df8 d@harpo.marx...
>>><snip>
>>>
>>>>As the OP said, it becomes an issue when you have multiple threads
>>>>(lightweigh t processes) in a single process, because (some) state is
>>>>shared between multiple threads of execution.
>>>
>>><snip>
>>>
>>>Minor nitpick:
>>>
>>>Reentrancy is not just a multi-threading (lightweight processes) issue,[/color][/color]
>
> but
>[color=green][color=darkred]
>>>arises whenever two threads of execution have access to some common
>>>function. Apart from the example given, this may also happen in[/color][/color]
>
> Interrupt
>[color=green][color=darkred]
>>>Service Routines (ISR's) or multitasking environments wich allow[/color][/color]
>
> concurrent
>[color=green][color=darkred]
>>>access to a shared resource.[/color]
>>
>>Pardon me but ... are reentrancy, multi-threading, ISR's and multitasking[/color]
>
> really
>[color=green]
>>a part of ISO C specification?[/color]
>
>
> Reentrancy is,[/color]

Would you point some fingers, please? Where can I find the ISO C specification
and, specificaly, where does it say anything about reentrancy?
[color=blue]
> for the simple reason that the standard lib is not guaranteed
> to be reentrant (and that is, IIRC, part of the standard). A further
> discussion of "reentrancy " brings on the other subjects.
>
> So while not being part of the standard, they (multithreading , ISR's and
> shared resources) are topical in this limited treatment.[/color]

[dandelion]

Re: re-entrant function??????? ?


"Eltee" <eltee@hotmail. com> wrote in message
news:34i0ddF40f 27bU1@individua l.net...[color=blue]
> dandelion wrote:[color=green]
> > "Eltee" <eltee@hotmail. com> wrote in message
> > news:34htveF4a8 v37U1@individua l.net...
> >[color=darkred]
> >>dandelion wrote:
> >>
> >>>"Trent Buck" <geragohpx@tznv y.pbz> wrote in message
> >>>news:2005011 1170803.4392df8 d@harpo.marx...
> >>><snip>
> >>>
> >>>>As the OP said, it becomes an issue when you have multiple threads
> >>>>(lightweigh t processes) in a single process, because (some) state is
> >>>>shared between multiple threads of execution.
> >>>
> >>><snip>
> >>>
> >>>Minor nitpick:
> >>>
> >>>Reentrancy is not just a multi-threading (lightweight processes) issue,[/color]
> >
> > but
> >[color=darkred]
> >>>arises whenever two threads of execution have access to some common
> >>>function. Apart from the example given, this may also happen in[/color]
> >
> > Interrupt
> >[color=darkred]
> >>>Service Routines (ISR's) or multitasking environments wich allow[/color]
> >
> > concurrent
> >[color=darkred]
> >>>access to a shared resource.
> >>
> >>Pardon me but ... are reentrancy, multi-threading, ISR's and[/color][/color][/color]
multitasking[color=blue][color=green]
> >
> > really
> >[color=darkred]
> >>a part of ISO C specification?[/color]
> >
> >
> > Reentrancy is,[/color]
>
> Would you point some fingers, please? Where can I find the ISO C[/color]
specification[color=blue]
> and, specificaly, where does it say anything about reentrancy?[/color]

http://www.iso.org, the costs are 340 swiss franks.

<quote 5.2.3>
[#1] Functions shall be implemented such that they may be
interrupted at any time by a signal, or may be called by a
signal handler, or both, with no alteration to earlier, but
still active, invocations' control flow (after the
interruption), function return values, or objects with
automatic storage duration. All such objects shall be
maintained outside the function image (the instructions that
compose the executable representation of a function) on a
per-invocation basis.
</quote>

<quote 7.1.4>
[#4] The functions in the standard library are not
guaranteed to be reentrant and may modify objects with
static storage duration.146)
</quote>

[Xenos]

Re: re-entrant function??????? ?


"dandelion" <dandelion@mead ow.net> wrote in message
news:41e3b1fd$0 $16996$e4fe514c @dreader8.news. xs4all.nl...[color=blue]
>
> Minor nitpick:
>
> Reentrancy is not just a multi-threading (lightweight processes) issue,[/color]
but[color=blue]
> arises whenever two threads of execution have access to some common
> function. Apart from the example given, this may also happen in Interrupt
> Service Routines (ISR's) or multitasking environments wich allow[/color]
concurrent[color=blue]
> access to a shared resource.
>[/color]
You are getting too caught up in terminology. An interrupt *is* a thread of
execution.

DrX

[Richard Tobin]

Re: re-entrant function??????? ?

In article <cs0m99$eog6@cu i1.lmms.lmco.co m>,
Xenos <dont.spam.me@s pamhate.com> wrote:
[color=blue]
>You are getting too caught up in terminology. An interrupt *is* a thread of
>execution.[/color]

Maybe. Or maybe it's just an involuntary function call. It depends
on your interrupts.

-- Richard

[CBFalconer]

Re: re-entrant function??????? ?

pete wrote:[color=blue]
> CBFalconer wrote:[color=green]
>> thesushant@redi ffmail.com wrote:[color=darkred]
>>>
>>> can anyone of C masters siting out there suggest any 1 example of
>>> re-entrnt function just to show what is the significance of that
>>> property and how we can exploit it ....[/color]
>>
>> #include <stdio.h>
>>
>> int putword(unsigne d long w, FILE *f)
>> {
>> if (w > 9)
>> if (0 > putword(w / 10, f)) return EOF;
>> return putc((w % 10) + '0', f);
>> } /* putword */[/color]
>
> Standard library functions aren't guaranteed to be reentrant, so,
> a function which calls putc can't be guaranteed to be reentrant.[/color]

True. Which points out that we need a putc call guaranteed to be
atomic, i.e. non-interuptable. All of which is OT here.

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[CBFalconer]

Re: re-entrant function??????? ?

Thomas Stegen wrote:[color=blue]
> pete wrote:[color=green]
>> CBFalconer wrote:[color=darkred]
>>> thesushant@redi ffmail.com wrote:
>>>
>>>> can anyone of C masters siting out there suggest any 1 example of
>>>> re-entrnt function just to show what is the significance of that
>>>> property and how we can exploit it ....
>>>
>>> #include <stdio.h>
>>>
>>> int putword(unsigne d long w, FILE *f)
>>> {
>>> if (w > 9)
>>> if (0 > putword(w / 10, f)) return EOF;
>>> return putc((w % 10) + '0', f);
>>> } /* putword */[/color]
>>
>> Standard library functions aren't guaranteed to be reentrant, so,
>> a function which calls putc can't be guaranteed to be reentrant.[/color]
>
> More importantly imo is that putc has a side effect on the file
> and so the function is not reentrant even on an implementation
> where putc is reentrant.[/color]

That side effect is under control, since f is a parameter.
putword, and even for that matter putc, can be interrupted and
called again, provided only that the parameters are different.
However if the function used putchar the criticism is valid.

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!