Making Access to project configuration threadsafe

[Kris Wong]

I haven't look at the API for this at all, but I'll chime in with some
knowledge on threading and concurrency.

1. Reading from an object is never a issue in a threaded environment.
Writing to an object is where concurrency issues arise.
2. Depending on the nature of how and when the configuration will be
accessed for reading and writing, there are different ways to handle
this.  Usually the more assumptions that can be made, the simpler the
implementation can become.

Here are two cover-all-bases approaches for handling this:

1. The project only gives out and accepts deep copies of the
configuration.  It will have one mutex which will be locked for long
enough to deep copy into another configuration object (in the case of a
read), or from another configuration object (in the case of a write).
The down side to this is obvious, it is inefficient.  The upside are
that it is a simple implementation and not prone to errors. Depending on
the size of the configuration object and the amount of accesses, it may
be sufficient.

2. The project has two methods, one which locks a configuration mutex
and returns a pointer, and one that unlocks it.  It then becomes the
responsibility of the caller to lock and unlock appropriately.  This is
obviously more efficient, and more prone to errors and incorrect usage
scenarios.

I may be able to come up with some better solutions if I have the time
to look into this further.

Kris Wong