From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2002-04-17 06:04:42
On 17 Apr 2002, David White wrote:
> On Wed, 2002-04-17 at 18:45, Itay wrote:
> > There are two issues which should be handled, otherwise users of this
> > vlarray will likely run into all sorts of undefined behaviors:
> > 1) Multithreading: The stack based allocator should be thread-aware to
> > prevent allocations from one thread to interleave with allocations from a
> > second one.
> This would be somewhat problematic. Potentially, there could be a
> mechanism for having a different "stack" for each thread. Suggestions on
> how this could be achieved are welcome :)
Policies? multi-threaded version has a container of allocators, hashed on
the thread ID? A faster alternative would be to require the user to
specify which stack they want. Both could be accomodated with something
StackAllocator GetThreadLocalAllocator(); // returns thread-local stack
vlarray(size_t Size); // uses GetThreadLocalAllocator()
vlarray(size_t Size, StackAllocator Alloc); // specify the stack
> > 2) Heap allocation of vlarray objects should be prohibited. It seems like a
> > simple problem with a simple solution (having a private new/delete
> > operators) but there might be side-effects/portability-effects which I am
> > not thinking of.
> Yes, that's what would happen; sorry, I forgot to mention this. Also,
> users wouldn't be able to create static vlarray objects, but I'm not
> sure if this can be enforced by the compiler. Functions called when
> initializing (or destroying) static objects may also be problematic.
I agree with prohibiting new/delete by whatever permissible means.
Probably a static vlarray would be pointless but I don't see why they
should be prohibited; isn't the compiler required to just "get it right"
with the order of destruction of static objects? As long as the allocator
structure itself is initialized before first use (some kind of nifty
counter?) I don't see a problem with using a vlarray in the
constructor/destructor of a static object either. Am I missing something?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk