Problem using IRIX 6.5 CC (MIPSPro C++) STL I/O w/ POSIX threads

After agonizing over this problem for a few days, I've decided to seek
help. No, not the variety that involes a jacket that zips up the back
but this august body of intrepid individuals.

After agonizing over this problem for a few days, I've decided to seek
help. No, not the variety that involes a jacket that zips up the back
but this august body of intrepid individuals. The problem is such:

I have written a simple test program that creates several threads.
Each pthread runs the same function: 1) it creates a
std::vector<std::string> and pushes several strings into the vector,
2) iterates over the vector printing its contents via std::cout, and
3) exits.

The problem that is occurring is that a simple line such as below

std::cout << "foo" << 1 << std::endl;

causes the program to crash.
Typically, std::cout cannot be used from multiple threads without
locking. This is true of all streams objects in general. If you want
thread safety, either use printf, or lock accesses to the stream.

Using Purify, I was able to determine that, for some oddball
reason, streaming an int to cout was the culprit. So then I begin to
play around...

std::cout << "foo" << '1' << std::endl; // works just fine 1 2
Even if this happens to work, you might have another thread multiplex
output at 1 and/or 2.
and also...

printf( "foo %d\n", 1); // this WORKS
Usually printf provides the necessary locking in a thread-safe
library.
I tested each of the above cases individually within my test app.
Every time that I said that it worked, I mean that the multithreaded
test application successfully ran to completion.

And, so, I am approaching wits end. I have run my same test
application on Solaris 2.9 using Sun Workshop C++ and it behaves just
fine.
It is possible that this is because Solaris disables buffering of
std::cout.

It's only with IRIX 6.5 MIPSPro C++ that I run into a problem.It seems reasonably clear to me
that this problem is specific to MIPSPro C++ STL I/O and, perhaps, its
handling of pthreads. I haven't as yet attempted this same experiment
with SGI threads as I'm not especially interested in the results. I
only wrote this test case as I have a customer who needs our product
to support IRIX 6.5 32-bit mulithreaded.

I'm fairly certain that this is not a locking issue as some of the
above cases work run without any hiccups within my threads.

In article <eb**************************@posting.google.com >,
Evan David Light <el****@acm.org> wrote: You do give the CC command line (helpful).
Really? I wrote this above:
CC -D_PTHREADS -D_POSIX_C_SOURCE=199506L -LANG:std -n32 -mips3 -c
<src> -o <obj>

You don't give any of
the MIPSpro compiler version involved
versions -b |grep ompil
the IRIX version involved (probably irrelevant, but which 6.5.x is it?)
a complete compileable and runnable test case.
(unless it's right there in front of me and I missed it...?)

I'd recommend locking all accesses to std::cout. Using a locking proxy
class is the usual approach (it locks on creation, unlocks on exit).
e.g.

//use comma operator!
#define COUT (LockingProxy(mycout_mutex), std::cout)

COUT << "whatever" << 10 << std::endl; //proxy destructs here.

tom_usenet <to********@hotmail.com> wrote in message news:<vr********************************@4ax.com>. ..

I'd recommend locking all accesses to std::cout. Using a locking proxy
class is the usual approach (it locks on creation, unlocks on exit).
e.g.

//use comma operator!
#define COUT (LockingProxy(mycout_mutex), std::cout)

COUT << "whatever" << 10 << std::endl; //proxy destructs here.

For simplicity's sake, I did the sample

pthread_mutex_lock
cout << ...
pthread_mutex_unlock

around all of my couts and I still encountered the same problem.

Have you tried creating a small test case, using pthreads
and cout, to see if you reproduce the problem?