On Nov 3, 2013, at 3:13 PM, Barry Smith wrote: > > 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. We currently have PetscThreadLocalXXX functions, defined in petscerror.h, to manage thread local variables. For example, PetscStack is managed using PetscThreadLocalXXX and is defined of the appropriate thread local type depending on the threading model type and the OS (see in petscerror.h). I think this is the only thread local variable that we manage currently.
On a side note, an additional complexity to think about is if the user wants to set different solver/user options for each thread. One possibility to handle this is to use prefix -thread#num_option_name for it but it looks clunky. Shri > 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 > > >> >
