Boost logo

Boost :

Subject: Re: [boost] Proposal: Monotonic Containers
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-17 18:10:52


> 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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk