Steven> Allowing both local storage and a single global storage in the same allocator type seems like a bad idea to me. If you don't do any locking, then the global storage will not play well with threads.
That is a good point. On considering this, I am considering introducing shared_allocator<T>. There is monotonic::static_storage<> and monotonic::static_shared_storage<> which is guarded with a mutex. There is also monotonic::storage<> and monotonic::shared_storage<> for local stores. I agree that there is room for error with these four different storage types. However, to use local storage you have to explicitly pass that to the container on construction, so the syntax and the intent are both clear: std::list<int, monotonic::allocator<int> > uses_global; monontic::storage<> storage; std::list<int, monotonic::allocator<int> > uses_local(storage); However, selecting which of static_storage or static_shared_storage to use is currently done with a function call. It seems that the following would be better: std::list<int, monotonic::allocator<int> > uses_global; std::list<int, monotonic::shared_allocator<int> > uses_global_shared; monontic::shared_storage<> shared_local; std::list<int, monotonic::allocator<int> > multithreaded(shared_local); There is a case to be made for removing the local storage types completely. But I personally use them, and want to continue to use them. Perhaps something like monotonic::potentially_unsafe_if_you_mix_with_other_storage::use_at_your_own_risk::but_it_can_really_help::storage<> could be provided. Even so, monotonic::static_storage<> is completely safe and isomorphic, and monotonic::static_shared_storage<> is completely safe and isomorphic for threaded applications. Thanks for the idea of introducing shared_allocator<T>. Regards, Christian.