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

From: David White (dave_at_[hidden])
Date: 2002-04-18 05:40:08

There are two seperate issues that we shouldn't get confused.

One is the issue of implementing it in a threadsafe way. This is
relatively simple - just place it in thread-specific storage.

The second issue is the issue of only creating the objects on the stack.
This issue can be only marginally abated by declaring operator new
private. The issue of using the object as a member and then allocating
on the heap cannot be stopped by the compiler. Thus, the documentation
would have to clearly state the way in which vlarrays should be used. I
don't see this as too much of a problem - many types of objects have to
have care taken with their use. Also, it should be fairly easy to make
the debug version of the allocator complain very loudly and very quickly
if someone tries to store vlarray objects in a prohibited fashion.

David.

On Thu, 2002-04-18 at 21:01, Eyal Farago wrote:
> 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
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost