Ok - I tracked it down. The issue is that we have a derived class from
PeriodicBoundaryBase that overrides get_corresponding_pos()... and even
though you made that function "const".... it turns out that you can still
call non-const methods on member variables of the class from a const method
if those member variables are pointers or references (see:
http://stackoverflow.com/questions/7390437/c-const-member-functions-are-modifying-member-variables)
In this case we were using a ParsedFunction inside
get_corresponding_pos().... and that thing is NOT thread safe in any way.
So when two threads were both asking for positions simultaneously they
were corrupting each other.
For now, I just put a spin_mutex in get_corresponding_pos()... which fixes
the problem.
However, I really think that what should be happening is you should be
using the clone() method for PeriodicBoundary to create copies of that
PeriodicBoundary for each thread... then we wouldn't ever have this
issue....
Derek
On Tue, Jul 9, 2013 at 10:34 AM, Roy Stogner <royst...@ices.utexas.edu>wrote:
>
> On Tue, 9 Jul 2013, Derek Gaston wrote:
>
> Nope - it's not that the PointLocator is NULL... the PointLocator is
>> _returning_ NULL (ie it couldn't find an element).
>>
>
> Is it possible that it's using the wrong translation vector somehow?
> One thread working on boundary pair A inadvertently pulling the
> translation vector from boundary pair B??
>
> I'm just guessing at this point..
> ---
> Roy
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
