Re: About 'futures'

[Mikael Djurfeldt <mdjurfeldt@gmail.com>]

On Tue, 08 Mar 2005 19:04:17 +0100, Marius Vollmer
<marius.vollmer@uni-dortmund.de> wrote:
> what is the difference between
> 
>     (join-thread (begin-thread (foo)))
> 
> and
> 
>     (future-ref (future (foo)))

The first construct is guaranteed to start a new OS thread with its
own, complete, dynamic context.  The indended usage pattern is an
application divided into a number of threads handling different tasks.
The implementation is optimized for the completeness of the
environment provided in the thread rather than, e.g., startup time.

The second is a lightweight mechanism intended for fast, small-scale,
parallelism, such as in the `letpar' or 'par-map' constructs which
evaluate its component expressions in parallel. The implementation is
optimized for quick start and delivery of the result rather than
providing a complete context rooted in a new OS thread. The current
implementation caches a number of "workers", so rather than spawning a
new thread, `future' simply implies signalling a condition variable.
(The current implementation is not complete since the dynamic context
is not re-initialized for each evaluation in a worker thread. In order
to complete the implementation one needs to define what "dynamic
context" includes in this case. The aim is that it should be minimal.)

> I am thinking about implementing futures as just
> 
>     (define-macro (future exp) `(begin-thread ,exp))
>     (define future-ref join-thread)
> 
> Would that make sense?

I don't think so for obvious reasons.  It would not make sense to
spawn new pthreads for the kind of usage patterns for which futures
are intended. In my opinion it's better to scrap futures entirely than
to provide the suggested implementation above.

But I would surely miss them. I have used these parallel language
constructs to make computations go faster on an SMP machine. It makes
beautiful sense when the subexpressions of a letpar are matrix
computations with operations implemented on the C level. Note also
that futures, by their nature, necessarily needs to be maintained
together with the guile-core rather than being provided by a separate
package.

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel