Re: Re-entrancy problems

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Mats Liljegren wrote:
> 
> Thanks for your quick response!
> 
> Some comments below:
> 
> > Unless you stick with XXX_r() functions, reentrancy support must
> > be provided as part of the by the underlying libgloss layer.
> > Powerpc-eabi probably does not have per-thread/process reentrancy
> > support.
> 
> I saw something about a global pointer that needs updating. I've thought
> about this, but haven't come up with a good solution for doing this. The
> problem is that this has to be done for every task switch, which means
> that it should be really fast. A really fast method would be to
> pre-allocate a re-entrancy structure for each process that could be
> created. By using the process ID, you could index this structure.
> 
> But as the maximum process ID for my OS is a 32 bit value, this would
> take more memory than I have...
>
> Is there anyone else that knows of a better solution?

RTEMS has task extensions.  We do EXACTLY what you are talking about.
We swap a pointer on every task switch.  The memory for the per-task
reentrancy area is allocated on a per task basis as part of the
task creation user extension.  It is initialized as part of the
task begin executing extension which covers restarting a task as well.
 
> > newlib 1.8.2 has some support locking that with a mutex but that
> > requires target specific glue also.
> 
> How does this glue work? I haven't seen this in the documentation I
> have.

This is new and I personally have not looked at it much yet. :(
I have been meaning to. :(
 
> Regards,
>   Mats

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985