Futurism lib (futures in D)

[Kevin Bealer]

== Quote from Mikola Lysenko (mclysenk at mtu.edu)'s article
> Saaa wrote:
> >
> > As I read it, futurism takes care of threading and synchronization of data
> > (between threads).
> >
> >
>
> Futures are a powerful technique to increase the parallelism of an
> application without much extra programming effort.  But as much as I
> like futures, it is Pollyannaish to claim that they solve all thread
> related problems.  Proper use of futures prevents the future threads
> from communicating altogether eliminating concurrency.  This is both
> good and bad; on the one hand concurrent programming is always risky
> business, yet in most situations involving threads concurrency is
> unavoidable.  A classic example is the dining philosophers problem.
> Each philosopher must communicate in order to share common resources.

I see some truth in this.  I also think the dining philosopher problem
would be less difficult if you have a controlling algorithm that can
arbitrate between the three philosophers -- in other words, the problem
is difficult because it is formulated as a peer-to-peer design.

I think there are tasks that futures don't solve.  For example, if you
want a status report written to a disk file every N seconds, or you need
to control access to a large central hash table, then futures are not the
normal solution to those kinds of problems.

But I don't see a conflict - I think you can have a status report thread,
a mutex-serialized hash table, and still use futures to multithread the
complex work loads.

There are different uses for multithreaded designs.  One of these is to
break up complex work, and I think this is where mutexes are awkward and
futures are elegant.

Kevin Bealer