On Nov 10, 2013 10:40 AM, "Jed Brown" <[email protected]> wrote: > > Barry Smith <[email protected]> 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.
