Yes.... periodic BCs have never worked with threading... they deadlock. We've just never got around to fixing it. Glad you tracked it down. If you're not going to have time to get to it just let us know.
Derek On Jul 1, 2011, at 12:40 PM, Roy Stogner wrote: > > I just noticed this while futzing with some related code: > > In FEBase::compute_periodic_constraints, we lock DofConstraints writes > with a spin_mutex, but those writes may be happening concurrently with > the unlocked reads elsewhere in the same function; and in that case on > our underlying STL map the read results aren't guaranteed to be > anything but junk. > > I'll try and fix this within the next week or so, unless someone wants > to add a proper RW mutex to Threads:: and beat me to it. In the > meantime be wary of running codes with periodic BCs active and > n_threads>1. > > This is just a threading race condition; parallel codes with one > thread per rank should still be fine. > --- > Roy > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Libmesh-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
