Re: Multithreading issues (was: KITTEN BOF at IETF 60)

Unfortunately the situation with multi-threading on Unix is
*extremely* platform specific *and* OS-Release specific.

As I mentioned, several Unix vendors have built multi-threading hooks
into their regular libc.so shared library so that there's a much better
chance that when mixing code that should not be mixed it doesn't
immediately crash on you.

Incompatibilities that I have encountered:
OSF1/Tru64: if an executable that is single-threaded and
            not linked with libpthread uses dlopen() to load a
            shared library that is linked with libpthread and
            used dlclose() before exiting, then this will result
            in a core dump on program exit.

HP-UX: The HP-UX 11.x compiler supports a non-posix storage specifier
       __thread to convert traditionally global or static variables
       into thread-local global or static variables.
       However if that feature is used in a shared library, then this
       shared library must be loaded at process creation time by the
       system loader, either a compiled-in dependency or by use of
       the LD_PRELOAD hack.
       If an application (even a multithreaded application) tries to
       dynamically load a shared library at runtime that contains
       "global" __thread variables, then this will result in an error.
       (this problem doesn't arise if the shared library creates
        thread local storage dynamically with the standardized
        POSIX function interface).
       It appears that users of the Java VM on HP-UX have to resort
       to the LD_PRELOAD hack because of this braindamage.

AIX during 4.2.1 had seperate libc libraries for single-threaded
and multi-threaded environments (a libc.a and a libc_r.a).
On AIX 4.3 and beyond both point to libc_r.a.
 
Unfortunately the OS vendors have heavily underspecified what can
be mixed and what can not on their various OS releases.

I did find a huge warning sign in the Compiler documentation of
Reliant Unix 5.45 (which is mostly a SystemVR4 Unix) and a linker
error when I tried to link objects where some where compiled
with only -pthread and others with -pthread -DUNIX98_THREADS.

I don't know whether others constantly recompile their code and
provide seperate version for every single OS version upgrade.
I prefer to ship as little individual binaries (apps and shared libs)
as possible.  It worked fine for regular single-threaded apps to
skip some OS releases, however with multi-threading support one
often has to provide seperate builds for every minor upgrade.
But it is also platform dependent.

Btw. I'm still using some HP-UX 9.0 binaries on HP-UX 11.11,
almost all of my 32-bit Solaris binaries are built on Solaris 2.6
and all of my Win32 binaries still work on Win95A.
and my oldest Linux binary shows build year of 1992. :)

This URL has compiled the thread maturity into a table
(I can not speak for the accuracy of that information):
http://homepage.mac.com/dbutenhof/Threads/ThreadTable.html


Ken Raeburn wrote:
> 
> > It depends how the shared object is linked. A threads shared 
> > object/module
> > must be loaded by a program that used pthread. Its not a requirement 
> > that
> > that libc (malloc/free/syslog etc) can handle any other situation.
> 
> But if you don't make the library depend on libpthread, as you did in 
> your example, would it tend to "just work" on most of these systems?  
> (Obviously there's a problem if there is no weak reference support, and 
> no stub versions of the mutex functions in libc, and the code actually 
> tries to lock a mutex or whatever.)

There is a lot of "just work" situations these days, but most of the
time it makes me sleep bad at night because it is HEAVILY underspecified
by the vendors.

> 
> > $ gcc -shared -o o.o o.c -pthread
> 
> This creates a shared library that references libpthread.  That would 
> definitely be bad to load into a single-threaded program.  If I compile 
> o.c with "-c -pthread", and then build a shared object ("-shared" but 
> not "-pthread"), I get something that runs successfully (sparc64 
> netbsd-current).

Unfortunately it is not well specified whether you will run into
problems (and which kind of problems) if an single-threaded app
that has not been linked with libpthread.so loads a shared library
which has been linked against libpthread.so and uses pthread calls.

On OSF1/Tru64 this appears to work--unless the application calls
dlclose() before exiting...


-Martin
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]