This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reentrancy support for multiprocessor systems


Likely, Grant wrote:
I'm working on a SMP PowerPC board that has 2 8260s on the same address bus.
The application I'm writing has no OS, so it simply has a seperate thread of
execution running on each of the processors.

The question that I have is with regard to the concurrent support for
reentrancy.  As far as I understand, newlib is fully reentrant providing
that each process has a seperate reentrancy structure, and the pointer to
that structure is stored in _impure_ptr.  The problem lies in the fact that
because the processors are executing concurrently and they share an
identical address space, I need to choose a value for _impure_ptr based on
the processor the code is executing on.  I cannot use the reentrant versions
of the library functions because I'm using a pre-written application in my
threads that I cannot rewrite to use the _r functions.

Is it safe to modify the _impure_ptr pointer to be a macro that calls a
function and returns the correct pointer?  (just like the errno macro?)  Is
there a better way to do this?


This is already done for you in libc/include/sys/reent.h. If you set the __DYNAMIC_REENT__ flag on while compiling newlib, then all references to _REENT will call a function __getreent(). You will need to supply a version of this function that can figure out which thread it is running under and pass back the appropriate reentrancy structure.

The flag currently must be set on manually and is meant to be set on in either
configure.host or libc/include/sys/config.h but it could be modified to be a
newlib configuration option.

-- Jeff J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]