Subject: Re: Threading problems
To: Arto Huusko <>
From: Bill Studenmund <>
List: tech-kern
Date: 11/24/2004 10:22:10
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 24, 2004 at 07:27:23PM +0200, Arto Huusko wrote:
> On Wed, 24 Nov 2004, Nathan J. Williams wrote:
> > "Johnny C. Lam" <> writes:
> >
> > As before, I would counsel caution as to whether the modules being
> > opened should, in fact, be linked against libpthread. This essentially
> > becomes "do they call pthread_create()"? For the applications that
> > have been listed earlier in this thread, is it possible to enumerate
> > the modules that link against libpthread and check them for this
> > property? I fear that a module is being linked against libpthread to
> > satisfy the module's attempts at thread-safety in the presence of a
> > threaded app, but the app isn't threaded either.
> Why only pthread_create()? I mean, how can a module be written
> so that it can satisfy thread-safety in the presence of a
> threaded app, without the module directly using pthread functions
> such as mutexes etc.
> Say a module has some global list, and functions add_to_list()
> and remove_from_list(). How can the module be written so that
> it magically is thread safe when the app is threaded?  To work
> with threaded apps correctly, it clearly needs to use
> pthread mutexes, and that in turn requires that the module is
> linked against pthread.

I'm not sure how official it is, but libc uses "threadlib.h". You can
include it and use "mutex_t" and "cond_t" and such. Then mutex_init(),
mutex_lock(), cond_signal(), cond_broadcast() and friends. If libpthread
is around, the calls map to pthread_ (pthread_mutex_lock(),=20
pthread_cond_signal(), etc.) calls. If libpthread isn't around, the calls=
map to the "do nothing" calls in libc that started this thread.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)