On Fri, 17 Jun 2011, Derek Gaston wrote:
> hmmm.... so you're having issues with it? No, luckily; I was just looking at the code for optimization reasons and noticed the potential problem. Incidentally, I can't believe there's no way to make this function any faster... but I've tried two other algorithms and one other data structure and so far everything's been 10%-20% slower than Ben's version. :-P > I haven't seen any issues with SparsityPattern with threads and we > run with threads a lot. But we certainly could have just gotten > lucky. Yeah, it seems like a case that really would only hit a tiny fraction of the time. If 1% of the nodes are shared between two threads, then you're only going to have them looking at the same node 0.01% of the time... and even in that case, most of the expensive work being done on each node isn't in contention... and even when there *is* a contention, as long as it just produces a wrong result rather than a memory corruption error we'll never notice - it'll just make PETSc have to do some slower allocation later. > If there is something specific you want us to look at I can have > David check it out on Monday. He is getting _really_ good at > tracking down threading bugs. Line 2053, we grab a row for a particular DoF index. There's no thread locking being done that I can see. Lines 2057, 2071, 2097, 2136 have read-only operations on that row which are capable of being invalidated by concurrent write operations, and lines 2059, 2099, 2103, and 2142 have write operations. --- Roy ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
