Thread safety of vtkMPIController::SetGlobalController()

Support
1

Hi,

I’m playing around with trying to do some pipeline processing with MPI parallelism in detached threads. As an example, I have 20 MPI processes and on 5 of them I detach a thread with their own vtkMPIController (with 5 MPI processes, I’ll call this controller S) that’s a subgroup of the global vtkMPIController (with 20 MPI processes, I’ll call this controller G). In the detached thread I want to set the S to be the “GlobalController”, i.e. do vtkMPIController::SetGlobalController(S);. When I do this though this actually changes the global controller in the main thread on those 5 MPI processes, i.e. if I do vtkMPIController::GetGlobalController(); I’ll get back S and not G. Should this be the expected behavior or is it a bug?

Thanks,
Andy

ps. To be specific, what really seems to be happening is that the WorldCommunicator, e.g. what you get from vtkMPICommunicator::GetWorldCommunicator(), doesn’t seem to be thread safe. In essence though it’s the same issue of not being thread safe.

2

Yes, this smells a lot like there are missing locks. I went through a while ago (!8732) and found a lot of improper MPI controller tracking. This may be involved.

Yes, there is only one global controller. There is no per-thread MPI controller.

Also, if there are vtkWeakPointer instances around, these are 100% thread-unsafe (the only valid things to do are to construct and destruct them; every provided method is a potential unchecked race condition).