On Nov 3, 2013, at 5:28 PM, Jed Brown <[email protected]> wrote:
> Barry Smith <[email protected]> writes:
>> 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.
>
> PetscStack is already thread local. I would be in favor of putting all
> the global variables into a single object, making all the internal
> functions take that argument explicitly, and making the top-level user
> interface grab the thread-local object before passing it to the internal
> functions.
What are “internal functions” in PETSc?
Why not just grab the appropriate global indexed by the thread as needed
instead of “passing it to the “internal functions”? That is why do some
functions “grab the thread local object” while other functions "take the thread
local object as an argument explicitly”?
It also seems that there are two distinct decisions that do not have to be
made together
1) Keep all global state in a single global object, instead of one for stack,
one for options, one for …
2) Index global objects by thread.
We can do 1 and 2, 2, or 1 (1 by itself would not support threads)
But regardless it seems like a bit of refactoring, not one day of work that
we could be confident would work well as a long term solution?
Is there anything good we can tell our current user Ed who wants to do
something now?
Barry
> Yes, we would have to know whether they liked pthreads,
> __thread, or OpenMP to declare the thread-local variable.
