Boost logo

Boost Users :

From: Kirit Sælensminde (kirit.saelensminde_at_[hidden])
Date: 2007-07-26 02:34:02


Ovanes Markarian wrote:
> On Wed, July 25, 2007 17:06, Andrew Holden wrote:
>> Ovanes Markarian wrote:
>>> Thanks for you link, a very interesting one ;) I ment this
>>> one in my previous post:
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2276.html
>> Another interesting technology. I'll need to examine it more closely.
>> It looks similar to TBB. Intel's implementation of TBB uses tasks and
>> thread pools. Instead of futures, it uses canned parallel algorithms
>> that WILL complete before returning, thus freeing the user from worrying
>> that values might not be ready.
>>
>> It looks like the futures run at a somewhat lower level than TBB, which
>> is certainly not a bad thing. I can already see the beginnings of some
>> ideas where it might do things that TBB can't, like any situation where
>> you wish to launch a separate thread (or task) and forget about it. I'm
>> also intrigued by the option of waiting an a specific return value from
>> the thread instead of joining the entire thread, like in boost.thread.
>>
>> I find myself wordering if this would be a worthy addition to
>> boost.thread. It looks like you could use a boost.thread condition
>> object in the implementation of a future.
>
> AFAIK Peter Dimov did some technology evaluation and implementation for futures. I also saw that
> Howard Hinnant was working on futures. May be there are already some implemenations which prove
> the concept.

I've also implemented futures on top of Boost.Thread. It's not a very
difficult task (about 100 lines of code), which I've been meaning to
write up for my web site.

If anybody wants to start playing with futures and comparing them to
message passing systems I've built a multi-threading JavaScript host
that's implemented on top of the C++ future. It uses futures and message
passing so you can compare the two approaches.

For example, futures are only deadlock free if you don't have any cyclic
dependencies between threads. If you can keep a tree structure it won't
deadlock. Using only message passing you get a deadlock free system, but
the code has to be re-structured as you can't have return values from calls.

K


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net