Global variables and MPI

Question

I know that global variables are bad and should be avoided as far as possible. However, when writing parallel programs with MPI for example, some variables only get initialised once, and never changed (This task's number, total number of tasks etc.). Is it still considered bad practice to have these variables as global? Since you pretty much need access to these variables all the time, it seems silly to make a class for them in main, and pass a pointer to it to 99% of all the functions in the program. My approach so far has been to hide them in a namespace mpi_glob (for the case of C++, I guess I would not bother to put them in a struct in C to emulate a namespace). I guess the question also goes for other set-only-once variables such as a system of units etc.

Answer 1

I suppose Singleton should help you managing it better, so you dont have to pass the pointer around. Practically, mpi_glob does the same, Singleton is just more accustomed way.

Alternatively, you can still resort to global variables - they are not bad as such. If you want to emphasize one-time assignment you can declare them const and set them via static initializer like this:

const int number_of_tasks = get_preconfigured_number_of_tasks();

If your global variables are used to hold compile time constants, then it is perfectly fine to replace them with enum members or preprocessor defines. Doing so will ease up on compiler, because it can use immediate value in-place without memory access.

---

Credit goes to Pete Becker for pointing Singleton issues in his comment. If those issues bother you too, then totally different approach can be taken.

Remember how Java programs are implemented? There is main class with main method and all program's work runs from inside that main method. Main is still member function, i.e. it can exclusively access some private fields of the main class (they have to be static in case of Java, but this is not the main point here).

We can further extend the concept to Command-like implementation. The difference with conventional Java is that your main method equivalent is not static and your global variables with values specific to contained program are non-static member variables. All functions that need access to global state data are to be converted into member functions. This is possible, because main method is also member function.

This way, I think, you can achieve better encapsulation and data safety.

Answer 2

The reason that global variables "are bad" is that they introduce coupling between separate source files that can be hard to identify and trace. In particular, if a global variable has an unexpected state at some point in the program, it can be hard to figure out where it got modified.

Replacing global variables with local variables that get passed by reference to every function in the program doesn't eliminate that problem. In design terms, it's "tramp data", i.e., data that wanders around even where it's not needed.

Now, the point here is that, as you suggest, data that's initialized once and never changed doesn't have the problems that make global variables "bad". Since the problem doesn't exist, the solution isn't needed.

Answer 3

No rule should be followed over a cliff, and the specifics depend entirely on what sort of program you're writing.

If your program is relatively small (or you're the only one writing / maintaining it), then it's probably fine to leave "global" variables in a special namespace. At least that way you're not likely to accidentally shadow or stomp on them in a local scope somewhere. That's assuming you're not doing something like this though:

using namespace mpi_glob;

Which is little different from just having the globals in a file somewhere and doesn't protect them very much.

If it makes your program more clear and easy to understand by using global variables, then use them. If it's possible to keep them local, keep them local, because it will usually make maintenance simpler in the long run.