Re: [boost] Futures Review Starts Today - January 5, 2009

Subject: Re: [boost] Futures Review Starts Today - January 5, 2009
From: Oliver Seiler (oseiler_at_[hidden])
Date: 2009-01-07 16:22:35

Some background on myself to give context for this review:
- Long-time user of boost in commercial C++ development
- Making extensive use of threads and related constructs
- Using home-brew future-like API for managing inter-thread communciations

> What is your evaluation of the design(s)?

As others have noted, futures now appear in the draft C++ standard,
and Anthony's API conforms closely to that (or, more correctly, the
draft C++ standard appears to be based on Anthony's API). Unless I
have some reason to think the draft C++ standard will completely
change the proposed future API, I would tend to support Anthony's API.
As Anthony has said in this thread, if conformance to the draft C++
standard future API is required for inclusion, he would help with that
effort, for either API, which is fine with me.

Design-wise, I prefer Anthony's API as it seems simpler to use;
Braddock's API includes things of questionable value (to me).
Specifically:
- callbacks seem tricky to use/implement safely
- future streams seem unnecessary at this point

Braddock's API does try to address the notion of scheduling. One of
the problems I've run into in using threads in C++ is that it is very
important to treat threads as resources to be managed just like other
limited OS resources. It generally isn't enough to say "oh, we'll just
execute this on another thread"; this can often lead to a situation
where you run out of threads, especially when thread execution can
block. Scheduling, deciding when a thread can run (because futures
that the execution is dependent on have become available), is a tricky
notion in C++, because a thread blocked waiting for a future is taking
up a limited resource, but without that thread waiting nothing will
take action when the future does become available; Braddock's API
tries to address this using callbacks.

I don't think this is the correct approach. In C++ specifically,
dealing well with threads requires care, by strictly limiting the
number of threads being used and taking great care to avoid deadlocks
and blocking among those threads; I don't think this is trivial.
Thread-pools are probably the wrong general approach, though they may
be appropriate in some contexts. It would be nice if some of the
designs allowed for waiting on multiple futures; this would allow
off-loading waiting for futures that looks hard to do in Anthony's
API, but could possibly be done in Braddock's.

Not sure if I'm explaining myself well here. In the product
development I do, we often wind up dealing with situations where
blocking a thread would cause lots of problems (specifically running
out of threads), so there is typically a lot of additional complexity
around ensuring that this doesn't happen.

> What is your evaluation of the implementation(s)?

Anthony's implementation looks simple and straightforward; not much
that I can say there. Braddock's is bigger, as goes with a bigger API.
I'm glad that both APIs come with a test suite.

As for Braddock's implementation, as I noted above, I'm not convinced
of the need of the future stream. Implementation-wise, it seems
complex. Based on Herb Sutter's recent forays into writing lock-free
queues that perform well on modern multi-core hardware, I'm skeptical
of the claim of "low lock contention" that the documentation makes.

Note that I'm not against the concept of a future stream; I have
implemented something similar in my application. Just don't think it
needs to be part of the library.

> What is your evaluation of the documentation?

Both seem complete. Overall I prefer Anthony's for succinctness, but
it is a simpler API as well, which helps.

> What is your evaluation of the potential usefulness of the library(s)?

As I said, I've implemented my own future-like API; having one
available in boost would have been nice. There are many contexts that
I would like to have one, every day :)

Many jobs ago, I was introduced to futures (can't recall exactly;
either through some beta version of Metrowerk's Powerplant library or
on some MacHack CD, though I suspect the former), and have only
started to see the concept pop up again in the last couple years. I'm
pretty happy that they look to be coming into the C++ standard.

> Did you try to use the library? With what compiler(s)? Did you have
> any problems?

Have not tried to use either.

> How much effort did you put into your evaluation(s)? A glance? A quick
> reading? In-depth study?

Somewhere in between...

> Are you knowledgeable about the problem domain?

I'd like to think so, but I keep learning more and realizing that I
don't know as much as I think I do...

Having said that, my current thinking is that using threads
effectively in C++ is difficult, and a lot of the reason for this is
the programming model itself. I suspect that effective use of multiple
processors/cores could be done better in interpreted languages (my
favourite model probably being something like Rob Pike's Newsqueak).
If starting a new C++ project today, assuming I was dealing with a
high-performance, mission-critical app, I would be probably be
structuring code with threading in mind, the goal being to keep a
small number of threads busy with none of those threads blocking, with
waiting (I/O, asynchronous waits, etc) happening on a small number of
additional threads. I'd probably avoid using thread pools entirely,
based on experience.

> Do you think the libraries should be accepted into Boost as-is or
> should they be merged?

As discussed, now that there appears to be a proposal in the draft
standard, I would expect boost to at least have a matching API. As
Vincente noted, it strikes me as odd that C++0x already has an
proposal for the API in the draft and we're trying to decide what will
make it into boost. The only reason I can see for putting a future
library into boost at this point is to gain experience with the API to
provide feedback for the C++ standard, until C++0x is defined and
available in popular compilers.

Additional things (e.g., future streams, callbacks) could be added as
new boost extensions to C++0x API, but they should then be re-worked
to fit that API...

IMHO...

Cheers
Oliver Seiler