[petsc-dev] de-global variablelizing PETSc

[Dmitry Karpeyev]

On Nov 10, 2013 10:40 AM, "Jed Brown" <jedbrown at mcs.anl.gov> wrote:
>
> Barry Smith <bsmith at mcs.anl.gov> writes:
> >   1) Hmm, the check for “initialized” of something is done often and
> >   through out the run of the code. Will each thread through out the
> >   run of the code need to check the lock each time?
>
> No, the "initialized" variable only ever changes in one direction.  The
> user should not have to call XXFinalizePackage() and if they really
> must, _all_ variables would have to be thread local (or make the PETSc
> library instance an object and pass it explicitly to every constructor
> [1]).
>
> >   2) Can the lock be made 100% portable and independent of the
> >   threading model etc that user is using?
>
> Independent of the threading model, but somewhat dependent on the
> compiler and/or architecture.  For example, C11 stdatomic.h is not
> widely available yet, and third-party implementations (like
> http://concurrencykit.org/) require inline assembly, which Cray's
> compiler suite does not support.  GCC has supported atomics for a long
> time and many vendors offer that syntax.
>
> http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/C-Extensions.html#C-Extensions
>
> >   3) Philosophy - why use a lock when it isn’t truly needed?
>
> MPI will be using a lock regardless if you use threads.  And the kernel
> uses locks all over the place (and more sophisticated techniques like
> RCU).  Locks are an important tool and one that I think is important.
>
>
> [1] This is the real way to support arbitrary threading models and
>     usage.  It would cause a huge (mostly-cosmetic) impact on user code,
>     but the idea would be that PetscInitialize() would return a "Petsc"
>     library context and _every_ constructor or function that currently
>     has global state would take this thing as its first argument.  Users
>     that want separate instances of the library in separate threads
>     would MPI_Init_thread() and pass their communicator to
>     PetscInitialize() (could call it PetscInitializeThread, but it would
>     take an explicit MPI_Comm parameter, though you could pass
>     MPI_COMM_NULL; the static variable PETSC_COMM_WORLD would have to
>     go, perhaps replaced by PetscCommWorld(petsclib)).

What would happen to VecCreate(PETSC_COMM_WORLD,&v)?
Would v now be a collection of threadwise Vecs?
How would they sync?
Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131110/4dbd9c6b/attachment.html>