Pavel Vozenilek wrote:
Maybe it could have threading policy, defaulting to the same mechanism shared_ptr uses, other options being no-locking and user-locking.
To mirror another message I sent regarding aligned_storage, I like the idea of making this library a part of boost, but I don't like the idea of having countless dependencies upon boost. Because a singleton doesn't do any multi threading itself, it shouldn't rely on a full fledged threading library at all. The only thing really necessary is to make the singleton library thread safe when used in the context of multiple threads. I would think this would be as simple as passing in a class which can be used as a mutex, locking upon creation and unlocking upon destruction. If there are further safety issues of which I am unaware, I think it does make sense to provide *the interface* for them in a single-threaded safety policy (leaving empty definitions). Any commonly used thread safety policies that require a specific major threading library (like boost's) could be provided in a separate header. The main thing that I would like to know is what this thread safety *interface* should look like, if it should provide any features other than locking, and/or how specifically it should be used within the singleton itself (aka what operations need to be locked). -Jason