Re-entrancy problems
Joel Sherrill
joel.sherrill@OARcorp.com
Mon Dec 4 06:28:00 GMT 2000
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
More information about the Newlib
mailing list