On Tue, 9 Jul 2013, Derek Gaston wrote:
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
)
Yup.
Which isn't entirely surprising (pointer-to-const is not the same as
const-pointer), but when you think about it I'm actually kind of
surprised that there's no std:: smart pointer that allows class
designers to enforce the alternative "if I'm const I can't modify what
I'm pointing to" semantics instead.
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.
Glad you found it!
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....
That's a little tricky, since you'd basically have to clone the whole
PeriodicBoundaries structure... but I'm still inclined to say you're
right. Would you guys mind putting together the patch?
Thanks,
---
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
