Re: [Dev-C++] about "reentering code" [was: itoa - simple implementation]

[Per W. <pw...@ia...>]

Since the caller supplies the buffer, itoa() then doesn't need to touch
any global variables.

That makes it possible for one thread to call itoa(), a task switch to
happen and a new new thread to call itoa() without either a static buffer
being corrupted by the two concurrent calls, or the second thread being
blocked by a critical section.

With a unprotected static buffer owned by itoa(), a second call from
another thread while itoa() runs, or before the first thread is done with
the returned pointer, would clear the static buffer and immediately try to
reuse it.

If the static buffer is protected by a critical section or mutex, then
only one thread at a time may use the buffer INSIDE itoa(), while any
other callers will be blocked until the first itoa() call returns.
However, the calling program will not be able to use the static buffer
before the next call from the other thread destroys the buffer.

If the buffer is dynamically allocated, each concurrent call of itoa()
will have their own buffer. This makes the call thread-safe. However, the
allocation malloc(), calloc(), strdup(), new or whatever, must access a
global list of available memory blocks for performing the allocation. To
make these functions thread-safe, they will have to protect the actual
allocation within a mutex or critical section. While this makes them
thread-safe, it doesn't make them fully reentrant, since a second
allocation call may not finish until the first allocation is through. This
will force the second thread - doesn=B4t matter how high prio it has - to
lock up until the first allocation is done.

If implementing a ISR - interrupt service routine - it would not be
alloced to cal the allocation function, so it woun't be allowed to call an
itoa() that uses dynamic memory. That is because while the interrupt
routine is active, there isn't possible for the OS to activate any
threads. The thread calling itoa() would then permanently lock the ISR
from ending, resulting in a dead-lock.

When you send in the buffer as a parameter to itoa(), you never get that
kind of problem, since each caller themself arrange for needed memory in a
suitable way. All running tasks have their own stack so an auto-allocated
buffer works find. As long as the buffer isn't large enough, the ISR may
also allocate a buffer on the stack - it will denepnding on OS either have
it's own OS-reserved stack, or using the free area of the currently
running thread's stack.

/Per W

On Wed, 2 Apr 2003, Luigi Santillo wrote:

> Hello Per,
>
> I see that you have mentioned that an implementation of itoa
> which has the interface:
>
> void itoa(int n, char *s);
>
> would be "reentrant". This concept is not clear to me, I would
> appreciate if you could elaborate a little about it, for instance
> you could point out the weakness (or "reentrancy" problems) related
> to the interface
>
> char *itoa(int n);
>
> and how these would be solved adopting the 2 parameters - void returning =
-
> function.
>
> TIA
> --
> >> gisan >>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>