to your question:
> Has anybody gone systematically thru a Posix standard doc, to
> figure out what is guaranteed to be thread dafe, and what is not?
I have done it and therefore I agree with your solution 170:7-9
"The MPI library should not invoke C/Fortran library calls
that are not thread-safe. E.g., in an environment where malloc
is not thread-safe, then malloc should not be used by the
MPI library."
I believe that there is no alternative due to the fact, that
portable application (the target of MPI) cannot handle on
a per-function-base the thread-safty or non-safty.
I have looked at the draft "POSIX AMENDMENT 2: Threads Extension"
that differentiates only between libc thread-safe or not (except a
well specified set, see below, the final standard I do not have)
and I have spoken with a thread's application programmer who told me
that there are really several libc that are not fully thread-safe.
The DRAFT AMENDMENT ISO/IEC 9945-1:1990/DAM-2 from 1994/95 says:
Page 14, new subclause Chap.2.3.9 thread-safty:
All functions defined by POSIX.1 and the C Standard {2} shall be
thread-safe, except that the following functions need not be
thread-safe: asctime(), ctime(), getc_unlocked(), getchar_unlocked(),
getgrgid(), getgrnam(), getlogin(), getpwnam(), getpwuid(), gmtime(),
localtime(), putc_unlocked(), putchar_unlocked(), rand(), readdir(),
strok(), ttyname(). The functions ctermid() and tmpnam() need not be
thread-safe if passed a NULL argument. Implementations shall provide
internal synchronization as necessary in order to satisfy this
requirement.
Page 16, new subclause Chap.2.3.9.2 thread-safty:
Where the interface of a function required by POSIX.1 or the
C Standard {2} precludes thread-safty, an alternate form which shall
be thread-safe is provided. The names of these thread-safe forms are
the same as the non-thread-safe forms with the addition of the suffix
"_r". In some cases, thread-safty is provided by restricting the
arguments to an existing function.
Page 24, Addition to Chap.2.9.3, Table 2-10
{_POSIX_THREADS} If this symbol is defined, the imple-
mentation supports the Thread Option
{_POSIX_THREAD_SAFE_FUNCTIONS} If this symbol is defined, the imple-
mentation supports the Thread-Safe
Function Option
Page 24, Addition to Chap.2.9.3
If the symbol {_POSIX_THREADS} is defined, then the symbol
{_POSIX_THREAD_SAFE_FUNCTIONS} shall also be defined.
Page 24, new subclause Chap.2.9.3.1
As mentioned elsewhere in this chapter, thread-safe functions are
useful beyond a pthreads environment, thus the option
{_POSIX_THREAD_SAFE_FUNCTIONS}.
If pthreads are available, thread-safe functions are necesary for
correct operation of current application code.
Best regards
Rolf
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626
Germany rabenseifner@rus.uni-stuttgart.de