Andrew Stitcher wrote:
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.
Its not useless, and it doesn't need to be recursive. It is useful precisely for
protecting the critical section of a singleton which may run in a static
construtor. It should be used only for static mutex memebers or global mutex
variables - e.g. if we need to put mutexatter in a singleton, we can protect the
singleton with a PODMutex.
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.
POD mutex is not recursive and never will be. It's intended only for the
restricted situation of a static initialized mutex.
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 agree - and PODMutex is the tool we can use to acomplish that. I can give this
a shot but probably not today, I'll put it on my list.
An even better solution would be to drop use of recursive mutexes, which are
evil, but I don't know how big a job that is. Most of the code is written with
the intent that it not require a recursive mutex but there may be some places
that will deadlock.
Cheers,
Alan.
