>> I seem to have had a classical deadlock, A was being assembled while >> some threads lurked around elsewhere. Adding some barriers seems to >> fix the problem, at least with the cases I currently have. > > Barriers should never affect the correctness of a pure MPI code that doesn't > do weird things like communicate through the filesystem. We use the barriers > for debugging, but they can generally be removed once the underlying issue > is sorted out.
Do you claim I should not use MPI_Barrier at all when only programming Petsc? Is really all required synchronization managed automatically? I do some raw MPI programming before and after, but not inside the Petsc core solver. > Also, when you say "threads", are you referring to MPI processes, or are you > using actual threads (e.g. pthreads or OpenMP)? I meant the MPI processes, sorry for the confusion. >> What I still miss is what would be the advantage of >> MPI_Barrier(((PetscObject)A)->comm) over >> MPI_Barrier(PETSC_COMM_WORLD). > > I don't know whether all processes on PETSC_COMM_WORLD are supposed to pass > through this assembly. If A was on a subcommunicator, then only those > processes should be calling assembly. Note that these communicators are the > same for many users. They are not the same for me, but I think I see the point now. Thanks, Dominik
