[boost] [futures] Future Containers?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-05-18 22:40:11

Hi Everyone,

I've been following the future implementation proposals that are set
to be available for review soon for inclusion in Boost. I for one
would like to look at the implementations in their "review-ready"
forms before doing an actual review of the different (competing?)
implementations. However, before it goes out there, I would like to
throw something into the mix.

Right now, we've been discussing futures that contain individual
values -- I know, these values can be containers, or practically
anything that can be referred to with a pointer. That being said, I'd
like to look at a broader application of future containers in the form
of asynchronous random access containers.

First, let me set up why I'm interested particularly in this matter.

I'm looking at being able to map a function to a range and being able
to asynchronously access certain parts of the container from multiple
threads and perform operations on them. This marries the functional
programming notion of function application, with asynchronous/parallel
programming with "lazy values" -- only here, the values are actually
computed in parallel or in separate threads (accessed through
futures).

So given for example:

transform(
  input.begin(), input.end(),
  back_inserter(output),
  function_returns_future
);

It would make 'output' be a back insertion sequence (or a container
that supports .push_back) that contains futures. Now this would be
fine, but now the problem becomes this:

In the case of an associative container for example, we'd have a
pair<key, future<value> > -- since futures cannot be default
constructable in either implementation, I don't think code that does
something like:

map<int, future<int> > container;
container[0].wait(); // dunno what happens here

Will compile.

Right now, having futures non-default constructable makes it hard(er)
to put them in standard containers.

This now begs the question: Will there be, or should there be, special
classes of future containers that would specially be defined to work
with futures? For example, in associative containers we should be able
to access the elements using the index operator without having to
explicitly call 'wait()', or perhaps have special future container
iterators that allow for waiting on a future when dereferencing
"pointed to elements".

Is there a thrust towards developing a future-aware class of
containers parallel to the STL containers?

I personally think this will be a game changer in helping people
transition towards and actually maximizing futures.

I'd love to hear your thoughts on this.

Have a good day everyone.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.