Thread safety of cout

[Dan Evison]

thanks.

> It would help, but is material more suited for a complete Bugzilla PR...

Well, I have just been trying to replicated the problem with a simple test
program with multiple threads writing similar information to cout and can't
get it to lock.  So I'm not sure exactly what the problem is.  If I can
reproduce the problem I'll definitely fill it in on Bugzilla.

In the application there are 17 threads, and threads 3, 4, 14 and 16 are
blocked in flockfile.  [They are all trying to write a const char * to
cout].  Thread 17 seems to be stuck in fflush().  [It is trying to do cout
<< endl].  I believe the other threads are not relevant.  Threads 3 and 4
are normally high cpu users (each approx 90% of a CPU), but the system was
almost completely idle, suggesting that 3 and 4 were blocking.

This deadlock has happened twice, and I saved a gdb trace of each thread the
second time, gdb.log.complete.  If someone could have a quick look at
gdb.log.edited, (with has relevant info stripped out from gdb.log.complete),
perhaps something is obvious that I'm missing.

By the way, the application writes very little to cout - just a few short
log messages per second - in total from all the threads.   The application
had been running successfully for about 5 hours when this happened.

> Anyway, it's difficult to answer your question without knowing the
> details of your
> system, in particular the version of glibc;

System is using libc-2.3.2, gcc 3.2.3, Linux kernel 2.4.24 on a dual Athlon
MP server.  Compiled -O3 -finline-functions.  Let me know if any other
details would help.

> see also:     http://gcc.gnu.org/ml/libstdc++/2003-04/msg00285.html

I'm not explicitly using locales so perhaps this isn't relevant.  The
threads are using std::left and std::setw though.

> Current versions of gcc(i.e., 3.4.x)/glibc(i.e., 2.3.x) are OK wrt the
> locale issues that affected older releases.

I would really appreciate any ideas related to this.

I'm planning on wrapping all calls involving cout with a mutex, but wonder
if (in theory) that should be necessary.

thanks!

Dan Evison
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb.log.complete
Type: application/octet-stream
Size: 41490 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20041007/973abc1c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb.log.edited
Type: application/octet-stream
Size: 16282 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20041007/973abc1c/attachment-0001.obj>