Andrew Stitcher escribió:
On Thu, 2008-06-05 at 14:39 -0400, Alan Conway wrote:
Andrew Stitcher wrote:
On Thu, 2008-06-05 at 19:31 +0200, Manuel Teira wrote:
...
initMutexattr[1](once: 0xffffffff7e14e300, mutexattr: 0xffffffff7e1535f8)
initMutexattr[1](once: 0xffffffff7e14e620, mutexattr: 0xffffffff7e1535d8)
Mutex::Mutex with mutex at 0xffffffff7e14e680 and pthread_mutex_attr_t
at 0x0000000100400758
Error initializing mutex: 0xffffffff7e14e680. Error 0
AllThreadsStatuses ctor. Mutex: 0xffffffff7e14e680
[snip lots of other initMutexattr and Mutex::Mutex nonrelated calls]
initMutexattr[1](once: 0x00000001003f7730, mutexattr: 0x0000000100400758)
I suspect that the static nature of AllThreadStatuses could be involved.
Any thought?
I'm pretty sure you are correct about the static initialisation order.
One problem that your trace points out though is that we will get a
_different_ initialisation for each file including Mutex.h due to the
anonymous namespace used here - this wasn't the intention of this code.
I guess this needs to be fixed by creating a Mutex.cpp to hold this
anonymous namespace. However I'm not sure whether or not this is the
cause of your problem,although it can't help.
I think I may see the problem. Is all AllThreadsStatuses called (directly or
indirectly) from static constructors in other compilation units?
An object that is called from static constructors in other compilation units has
to be written in a rather special way - it has to be a POD and be POD
initialized - i.e. no constructors or destructors and no members/bases with
ctors/dtors.
It's the mutexattr static constructor that is the problem - that needs
to be written as a singleton and as I said before moved into an
implementation file.
We have a PODMutex for exactly that situation
PODMutex is currently useless (and isn't used anywhere as far as I know)
because it can't create a recursive mutex which is what Mutex is.
A piece of work we still need to do is to create a RecursiveMutex and
revert Mutex to non recursive then only make mutexes recursive that have
to be - then PODMutex might be useful again.
Andrew do you know the circumstances under which this is called? Manuel - can
you post a stack trace? That should answer the question.
I think that fixing Mutex so that its contructor can be safely called
from anywhere in static initialisation is the way to go here. I think
that the other issues are consequences of this lack. The problem is
exacerbated because there are multiple initialisations of the
mutexInitAttr one for every implementation file which uses Mutex so it
almost bound to fail in this way - it's amazing we've not seen it
before.
I think it was for the same reason that Mutex and RWLock were able to
share the pthread_once_t control without error in Linux. Non initialized
pthread_mutexattr_t are probably valid for the pthread_mutex_init call
in the Linux version (perhaps a zero inizialized struct is enough, and
the compiler is supplying that), but I think that the locks must be
failing randomly at least in the initial stage of the process.
Best regards.
--
Manuel.
Andrew
Cheers,
Alan.
.
