Pragmatic design pattern

I'm tearing into a poorly designed subsystem that has undergone two generations of "minimal changes" and has turned into a bloody mess. One of the interesting messes I encountered was how the program goes about communicating overall program options into two threads it starts: it copies the program options into per-thread options and passes the per-thread options into the thread. This seems dumb, since the program options are already stored in a global object.

I should probably point out these options are read-only once the command line and a configuration file have been processed, long before any threads are manipulated. Changing either the configuration file or command options requires restarting the program.

I understand that the programmer who did this was reading Design Patterns at the time, and sort of got the "reduce unstated dependencies" mantra, but copying options from a global just seems like a waste of both time and space.

So, what's the suggested way to store overall program options in a manner that a thread can access them without copying them?