Re: order of destruction, singletons & std::ostream

From:

Maxim Yegorushkin <maxim.yegorushkin@gmail.com>

Newsgroups:

comp.lang.c++.moderated

Date:

Fri, 10 Aug 2007 12:26:20 CST

Message-ID:

<1186761333.115166.301520@e9g2000prf.googlegroups.com>

On 8 Aug, 16:54, ThosRTanner <ttann...@bloomberg.net> wrote:

We have a class in our system which is a singleton and it has 2
std::auto_ptr<std::ostream> members.

You get hold of the instance by calling the getInstance() method which
is inlined and does
inline Fred& Fred::getInstance() { static Fred fred; return fred; }

And the program is multithreaded. Running on solaris, in case that is
relevant.

The issue is that sometimes on exit the program hangs, apparently
trying to acquire a mutex in the destructor of one of the ostream
objects. This destructor is called as the result of calling exit(0)
from the main program. And one of the other threads is still running,
and it is also locked on a mutex, though as far as I can see it is a
different mutex.

I realise that threading isn't covered by the standard, but is it safe
to get hold of pointers to ostream objects like that and then let them
be cleaned up during exit processing (especially as, as far as I can
see, the object won't have been constructed till well after main())
has been entered.

The problem seems to stem from the C/C++ and POSIX standards not
mentioning whether the other threads have been terminated when
atexit() handlers are being executed.

This particular case sounds like a deadlock: your destructor thread
gets blocked on a mutex. One possible fix would be to let the other
threads terminate gracefully (releasing mutexes and other resources)
before calling exit(), thus eliminating the possibility of the
deadlock.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]