On Thu, 11 Mar 2010, Kirk, Benjamin (JSC-EG311) wrote: >> Not quite - an idea which part isn't thread-safe? I thought that the >> only issue was the buffer for char*, and that declaring it as >> thread-local-storage was enough to fix it. > > see _requested_arguments, _requested_variables, _requested_sections > > it keeps an internal log of what variables have been requested so that it > can identify unused variables.
Ugh. This is one of the features that motivated moving to a newer GetPot - some of my own code does this "by hand" via some macro hacks and it's been incredibly useful. > multiple threads will call push_back() on these and madness ensues. Ah. And even tbb::concurrent_vector isn't concurrent *enough* to just replace them. > there seems to be a way to disable this but it didn't work for me at my > first go-around. Yeah, I must be missing something with how that feature works. All the accesses seem to be wrapped in tests of request_recording_f, but you're turning that off and it's still breaking? For that matter, I *was* missing one thing with how that feature works. I figured that making all the mutable GetPot members thread-local-storage should be enough to make all the const member functions thread-safe... but of course that doesn't matter when deep in the code you find some of the non-mutable members being accessed by casting *this to non-const! Could you let me know how to replicate the problem? Upgrading GetPot was my bright idea; I'll fix it. --- Roy ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
