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

From: Damien Fisher (damien_at_[hidden])
Date: 2002-04-17 19:45:19

On Wed, 17 Apr 2002, Ian McCulloch wrote:

> 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

Sorry, I must not understand what vlarray is doing.  I don't see how
multithreaded-ness can be supported any way other than one stack per
thread.  Suppose you have 2 threads, and thread 1 allocates a vlarray,
then thread 2 allocates a vlarray...thread 1's vlarray gets destroyed
first, then thread 2.  This will screw up the stack.

I mean, if vlarray is supposed to basically support stack based
allocations, then it will have the same problems that stacks & threads
have in other contexts.

Damien