On Nov 10, 2013, at 8:31 AM, Jed Brown <[email protected]> wrote:
> Matthew Knepley <[email protected]> writes: >>> 2) We need a way for initializing all the packages in PetscInitialize() >>> instead of as needed. In master I see >>> >> >> I really do not like this since then we are creating circular dependencies, >> and people who would like to "use >> only a part" will be upset. What about having the user who wants completely >> threadsafe stuff call *Initialize(), >> and then have this cascade all the way down (I think it should anyway). > > Why is it not enough to have a lock for initialization (or anything else > that needs to modify the remaining globals)? Those functions are not > performance-sensitive, so the locking strategy need only be immune to > deadlock, not high-performance. 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? 2) Can the lock be made 100% portable and independent of the threading model etc that user is using? 3) Philosophy - why use a lock when it isn’t truly needed? Barry
