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