On Nov 10, 2013, at 6:38 PM, Jed Brown <[email protected]> wrote:
> Matthew Knepley <[email protected]> writes: >> This all seems like a terribly convoluted and fragile solution to this >> problem. If we stack this up against some >> extra configure work to get the lock call right, I think that is a clear >> win. > > I agree that the initialize stuff is totally overkill for threading, > though PetscInitialize is currently somewhat brittle since adding new > arguments is intrusive and we currently have totally unprotected > globals. Changing to PetscSetCommWorld(comm) instead of > PETSC_COMM_WORLD = comm seems acceptable to me, however. > > Regardless, the fact is that even if part of a user's code solves > separate problems on separate threads (the tiny Vec case), the same code > should be able to turn around and create "fat" Vecs. Yes > I think we have to > offer the lock solution; What lock solution are you talking about? > other possibilities are optional, and I don't > think PetscInitialize has to change in a significant way for this reason > (though perhaps it should for some other reason). What do tiny or fat Vecs have to do with wether ISInitializePackage() and friends are called during some initialization or “when needed” (and thus requiring some sort of lock). BTW: I am not opposed to ISInitializePackage() using a lock to insure it is done only once per process, but I ain’t writing that code. Barry
