FW: pthread_mutex_init()

[Jim Parsons]

Hi Gang,

I have re-arranged this mail file into chronological order for easy
reading...

> >On Wed, 2 Feb 2000, Jim Parsons wrote:
> >
> >> Benjamin,
> >>
> >>   I hope you will indulge me with a private post directly
> >> to you...this is a sticky problem, and I am not even sure I can
word it
> >> right.
> >>
> >>   When linking with libpthread, our libstdc++ based application
dies in
> >> static initialization with a seg fault. It appears that
> >> pthread_mutex_init is being called with NULL  for the
pthread_mutex_t
> >> parameter from within the libstdc++ IO init routines. Is this a
known
> >> problem to you? Or am I missing a flag for threads when building
the
> >> library? I know that libstdc++ is not officially threadsafe, but I
am
> >> seeing behavior that appears thread broken.
> >>
> >>   If you think it is worthwhile, we'll post details and a proposed
fix
> >> on the list--I just have a feeling that you are probably aware of
> >> this...
> >>
> >> Thanks,
> >>
> >> -jim
> >>


> >From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ]
> >Sent: Wednesday, February 02, 2000 6:31 PM
> >To: Jim Parsons
> >Subject: Re: pthread_mutex_init()
> >
> >
> >
> >No. I'm not aware of this. What's your platform? Waht versions of
software
> >are you using?  There are a ton of people using GNU libstdc++-v2 in
> >thread-safe contexts.
> >
> >very important--you have to configure at the top level with
> >
> >--enable-threads=posix
> >
> >so that g++ and libstdc++ will have the correct flags passed down to
the
> >make files in their subdirs.
> >
> >-Benjamin
> >


 On Thu, 3 Feb 2000, Michael
Stevens wrote:

> Benjamin,
> 
> Attached is a patch file that resolves the problem with pthread
> initialization.
> It appears as if the system uses a global mutex for handling io to and
from
> the console.  We tried your suggestion (--enable_threads=posix) and it
still
> seg faults in the static initialization code constructor __basic_file,
it is
> calling genops.c
> without initializing a variable within the FILE structure namely the
pointer
> to the mutex.
> The patch file resolves this issue.  If you would like I can send you
a
> simple test
> program that demostrates the problem.
> 
> However, a simple hello world:
> 
> int main(int arg, char *argv[])
> {
>     cout << "hello world" << endl;
> }
> 
> will demostrate the problem if you link with
> 
> -lstdc++
> -lpthread
> 
> 
> The patch works well on Linux.  We have not tested it on other
platforms.

Mike




From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ]
Sent: Thursday, February 03, 2000 5:25 PM
To: Michael Stevens
Cc: Jim Parsons
Subject: Re: pthread_mutex_init()



oooooohhhhh. I thought you were using libstdc++v2. Duh. I hadn't tried
MT
stuff on v3, because I know the string stuff is not in. I just enabled
the
posix thread stuff for v3 this monday. . . hadn't even thought about
io.

Damn, you are getting ahead of me! (Nice to see though.)

:)

Please repost this thread to the list. I know it's a pain, but this way
other people will be able to search for it (and also I don't keep
personal
v3 email, instead using the web page archive . . .) Also Uli has some
stuff to say.

Basically, everybody's been emailing me privately about this. I'm sick
of
it. ..  :) (nathan, uli, now you. . .)

A couple of things:
1) yes. Even a minimal test case would be nice.

2) v-3's makefile/configure systems are not definig -D_I0_MTSAFE_IO
which
may be necessary for libio to be used in MT-safe contexts. This can be
changed with minmal effort.  ... or you could just do 3)

3) changelog stuff. . .

4) please use the new threads interface. Ie, instead of 
#including <pthread.h>

use

#include<bits/c++threads.h>


then things like 

+     static pthread_mutex_t _sync_mutex;

will have to have null definitions in the "no threads" case.

Hmm.

-benjamin




-------------- next part --------------
A non-text attachment was scrubbed...
Name: mikes_patch_for_libstc++_and_pthreads
Type: text/x-c++
Size: 826 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20000401/d8ab4a93/attachment.bin>