Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at