Re: Thread safe malloc in Tru64?

• Previous message: Jeff Donsbach: "Re: Tru64 compile/link problem"
• In reply to: Ioannis E. Venetis: "Thread safe malloc in Tru64?"
• Next in thread: Ioannis E. Venetis: "Re: Thread safe malloc in Tru64?"
• Reply: Ioannis E. Venetis: "Re: Thread safe malloc in Tru64?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Fri, 21 Nov 2003 08:16:31 -0500

Ioannis E. Venetis wrote:

> I am trying to create a library that will run, among other architectures,
> on Tru64/Alpha systems.
> Of course, this library has a machine independant (the same for all
> architectures) and a machine
> dependant part. For some reasons, I chose to use the
> thread_create/thread_get_state/
> thread_set_state/thread_resume/thread_terminate interface in the machine
> dependant part of the
> library to manage kernel-level threads on Tru64 Unix systems. I am
> mentioning it in case this has
> something to do with the problem I will describe.

Yes, that's extremely relevant. In fact, explanation is exactly and
exclusively the cause of your problems.

Direct use of Mach threading primitives is not SUPPORTED for user mode
applications. That is, nobody says it'll work, it's not documented, and if
you insist on doing it anyway whatever you get is your own responsibility.

In particular, in this case, the thread safety of all of libc (and other
user-space libraries) is a result of cooperation between those libraries
and the SUPPORTED/DOCUMENTED user mode thread implementation in libpthread.
Without libpthread, there's no thread safety.

> I searched the Internet and found that I had to link my
> applications with a few
> libraries, in order to make them thread-safe. Some of the possibilities I
> found are:
>
> -lpthreads -lmach -lc_r
> -lpthread -lmach -lexc -lc

You're already linking with -lmach, if you're using the UNSUPPORTED Mach
thread interfaces. Because libpthreads has a dependency on libpthread, and
both depend on libexc, much of this is redundant. (And while very old
versions of libpthread used Mach operations directly and required libmach,
this hasn't been true since V4.0D.)

The proper way to build a threaded application (using POSIX threads) is with
the -pthread switch (not -lpthread). If you must compile and link
separately, you can compile with -D_REENTRANT and link with -lpthread -lexc
-lc. (libc_r is nothing but a link to libc; once upon a time, in the days
of the threadosaurus, they were distinct, and the old name remains for
compatibility; but it no longer means anything.) If you were to use the
obsolete DCE thread or the archaic CMA interfaces, you'd use -threads,
which translates to linking with -lpthreads in addition to the others.

Furthermore, using POSIX thread synchronization in a thread created using
the Mach interfaces isn't supported, and that's really what you're doing
when you add -lpthread to your binary. The process is mostly prepared to
pretend to be threaded -- but it's not, really. All of your Mach threads
will think they're the same POSIX thread, and, well, it's not going to work
very well.

> Finally, I replaced malloc() with mmap(), and the applications run
> perfectly in this case, so I doubt
> that something else is wrong in the library.

Because mmap() is a kernel syscall, not user space code. You could "get
away" with using Mach threads if you didn't rely on any user-space thread
safety. If you're content to do that, go for it... but your application is
still going to be technically unsupportable and in my opinion it's not a
good idea.

> I would appreciate it if someone could give me some directions on how to
> link my libray and applications
> with thread-safe versions of all necessary libraries, both for shared and
> static versions.

Use POSIX thread operations instead of the unsupported Mach interfaces.
Build with -pthread, if the version of gcc you're using supports it; or use
-D_REENTRANT -lpthread -lexc -lc. Note that gcc doesn't integrate with
libexc (the Tru64 UNIX exception package); if you mix C and C++, C++
destructors won't run on thread cancellation and TRY/FINALLY/CATCH_ALL
macros won't work with C++ exceptions propagated through a frame. (This
will work with HP's compiler.)

-- 
/--------------------[ David.Butenhof@hp.com ]--------------------\
| Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/

• Previous message: Jeff Donsbach: "Re: Tru64 compile/link problem"
• In reply to: Ioannis E. Venetis: "Thread safe malloc in Tru64?"
• Next in thread: Ioannis E. Venetis: "Re: Thread safe malloc in Tru64?"
• Reply: Ioannis E. Venetis: "Re: Thread safe malloc in Tru64?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]