On Fri, 16 Aug 2013, Derek Gaston wrote:
We're seeing hard locks on some machines in Singleton::Setup::Setup()!
The problem is that it's trying to create a scoped_lock using a mutex that is
defined in that file.
Apparently that mutex is not guaranteed to have been initialized at the point
where we're calling that function (or
something) and it is just hanging while trying to acquire that lock!
Hmm... remote_elem_mtx should only get constructed at static
initialization time before main() gets called, and
RemoteElem::create() should only get called from
LibMeshInit::LibMeshInit() afterwards.
You're not creating a global LibMeshInit object, are you?
I commented out that scoped_lock line and then the binary runs just fine.
Hmmm... would you replace that global mutex with two locals? Maybe
there's some problem with a mutex constructor being called before we
init TBB?
Why do we need to lock in those functions? Surely the
Singleton::Setup stuff is NOT going to get called in a loop.
You're right; the Setup constructor should be called at static init
time and the setup() call should be at LibMeshInit constructor time.
How do we want to proceed?
It looks like we've got redundant locks that we can safely get rid
of... but I'd like to actually *understand* the problem too, and that
hasn't happened for me yet.
---
Roy
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
