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

From: Eyal Farago (eyalfa_at_[hidden])
Date: 2002-04-18 06:01:53

It is possible to store the stack allocator on the thread specific
storage, this way it can be allocated when the first allocation request
is made.

The original posting discussed a vlarray object that can be allocated
only on the stack, this means that the order of creation and destruction
is well defined, however there is a problem with this approach because
an instance of vlarray can be embedded into another class which in turn
can be allocated on the heap, this might 'kill' the stack allocator
since now the order of destruction is not so well defined(or not defined
at all).

I believe that the issue here is not about multithreading, it about
preventing this objects from being embedded into classes that their
instances might be allocated on the heap, after reading Scott Myers'
More Effective C++(sorry I don't recall the chapter), I can tell you
that there is no good way of finding out if an address is heap based or
stack based.

Eyal.

-----Original Message-----
From: Damien Fisher [mailto:damien_at_[hidden]]
Sent: Thursday, April 18, 2002 2:45 AM
To: boost_at_[hidden]
Subject: Re: [boost] Re: Query of Interest - vlarray

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

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost