Re: [boost] Re: Query of Interest - vlarray

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 
like

class StackAllocator;  

StackAllocator GetThreadLocalAllocator();  // returns thread-local stack

class vlarray
{
  public:
    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?

Cheers,
Ian McCulloch