[avr-gcc-list] RE: avr-gcc-list Digest, Vol 15, Issue 12

[Dafni & Robert Berger]

Joerg Wunsch and E.Weddington wrote:
"E. Weddington" <address@hidden> wrote:

>> Is the floating point library in WINAVR thread safe?

> The floating point library is a part of avr-libc and IIRC I haven't
> seen any assertion that says that avr-libc is thread safe at
> all. Perhaps one of the developers (Joerg or Ted) can comment on
> this as well.

There has only been limited effort on thread-safeness made so far.  I
think there's a strtok_r() function to be used as a thread-safe
replacement for strtok().  Most standard C library functions don't
keep local state (and when they do, that's normally obvious).

stdio is completely thread-unsafe (the implementation keeps a lot of
local state, starting with the file handle table), but I guess whoever
thinks about threads will be running some kind of OS, so is likely to
have their own implementation of stdio anyway.
[Robert] Your guess is wrong. I am using MicroCos-ii (ucos-ii) and it does
not come with any libraries. It's just the kernel and some OS services. This
means that for the AVR I have to use the standard C libraries that come with
avrlibc. Certainly you can always wrap functions into other functions, which
are made reentrant through semaphores. As far as I know, also big companies,
like Wind River are shipping the standard GNU libc for their libraries and
there are also additional functions like xxx_r, which are reentrant (maybe
made with semaphores).
Adding thread-safety
to it by default will heavily bloat it further (and it's already huge
as it is now).

As far as the FP lib goes, I think nobody has analyzed whether it
stores local state somewhere.  Most of it is written in assembler, and
while it probably doesn't use static storage, they are doing a lot of
trickery so I guess a definative answer cannot be obtained without an
in-depth analysis of the code (which simply needs one resource: a
volunteer).
[Robert] Regards,
Robert