From: Roy S. <roy...@ic...> - 2011-04-22 15:17:18
|
On Fri, 22 Apr 2011, Derek Gaston wrote: > On Apr 22, 2011, at 9:02 AM, Roy Stogner wrote: > >> In particular we can see failed assertions (and probably crashes or >> corruption) in multithreaded code that relys on the mesh-provided >> point_locator() incorrectly: MeshFunction, PeriodicBoundaries, >> ExactSolution/ExactErrorEstimator, and RBEIMSystem are likely >> affected. > > Thank god! We've known for a while now (like over a year) that > PeriodicBoundaries didn't work with threading... but never had time > to fully investigate! This could be it! Yeah, I'm now starting to realize how dangerous it is for me to keep adding more and more regression tests to BuildBot. Combine that with my Monkey's Paw wish to have people write more example codes and my Rain Man-like obsession with cleaning up every resulting mess, and it's making for a lot of work at a very inconvenient time. :-P >> I'd like to change point_locator() to return an AutoPtr instead, an >> API-incompatible change. The alternative would be to just deprecate >> the existing function and create a new one with a different name. Any >> preferences? > > Just change it. I'm sure there aren't _too_ many people using > PointLocator... and we can easily change the few places we use it. Will do. How about another change: making the PointLocatorBase an argument to PeriodicBoundaries::neighbor, Elem::periodic_neighbor, etc.? That's a little uglier and it's more API breakage, and it's not necessary for correctness, but it'll allow us to avoid constructing subordinate PointLocatorTree objects (with empty caches) over and over again, which ought to be good for efficiency. --- Roy |