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. I think we have to offer the lock solution; 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).
pgpaFifgdSqwo.pgp
Description: PGP signature
