On Nov 1, 2013, at 11:27 PM, Jed Brown <[email protected]> wrote:
> Barry Smith <[email protected]> writes: > >> hence are not thread safe. Is there any decent way to deal with this? > > Make those variables thread local? Or make the database an object > instead of a collection of global variables, in which case it can be > cloned for each thread to access (and manipulate). Whose thread local? OpenMP threads, pthreads, can this be done so it is all independent of the thread model that user is using. For example in this case the user is using OpenMP but PETSc doesn’t even know about threads, which except for a bunch of damn globals would be ok. The “globalness” of the Options object is mostly for the GUI options setting, but untangling just that case with #if def looks very messy. That is we could possibly get rid of the object when not using the GUI but that will require refactoring and maybe not as simple code. Barry >
