Re: [boost] [futures] Request for Comments

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2005-08-16 19:59:43

Oliver Kullmann wrote:

> I hope I can bother you with some general questions:
>
> 1) I've never heard the notion of a "future" in this context
> -- what does it mean?

A Future represents the result of an asynchronous computation. Methods are
provided to check if the computation is complete, to wait for its
completion, and to retrieve the result of the computation. The result can
only be retrieved using method get() or the operator()() when the
computation has completed, blocking if necessary until it is ready.
Cancellation is currently missing because of the missing
boost::thread::kill(). That's an open issue with the current implementation.

> 2) How is the relation of your library to the boost thread library?
> I only once looked into boost::thread, and I came to the
> conclusion, that it wouldn't be usable for me, since the main
> application for which I want to use threads is as follows:

The futures library is implemented on the top of boost::thread.

> Given two functions
>
> bool f1(X x);
> bool f2(X x);
>
> I want to compute the logical or (short-circuit!).
>
> Now boost::thread did not support thread cancellation or
> termination in version 1_32, and it seems that development of
> boost::thread has been cancelled itself.

It does not support thread cancellation in V1.33.0 either.

> To cancel a thread is essential to gain the speed-up possible
> by the parallel short-circuit evaluation, and thus
> boost::thread seems not to be usable.
>
> Now how are you proceeding? In the FAQ's of boost::thread one can read
>
> ----
>
> 9. Why isn't thread cancellation or termination provided?
>
> There's a valid need for thread termination, so at some point
> probably will include it, but only after we can find a truly
> safe (and portable) mechanism for this concept.
>
> ----
>
> How do you cancel threads?

We don't cancel threads for the reasons outlined above. I'm not a threading
expert but I think, that threads shouldn't be cancelled from the 'outside'.
Threads should generally cancel itself. Once boost::thread comes up with a
general solution cancellation will be added to the futures library as well.

> Can one compute the short-circuit parallel or with your "futures" ?!

The expression:

   int func1();
   int func2();
   future<int> f = int_[&func1] || int_[&func2];

Creates a composite future (every of the functions is wrapped into a
boost::thread), which when evaluated as

   int result = f();

either returns immediately if one of the functions (func1 or func2) already
did return, or blocks until one of the functions return. The return value of
f() is the value returned from the function, which finished first.

Is that what you've had in mind by mentioning 'shortcut evaluation'?

> 3) How is access to common storage handled with you approach?!
> (I would appreciate a short explanation using not too much jargon
> --- yet I have only written one multi-threaded program (and
> that to explore the boost::thread library).)

That's completely up to you. The futures library does not care about, what
the wrapped functions actually do.

Regards Hartmut