Re: [Boost-users] [thread] comparison with Intel Threading BuildingBlocks
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. Boost Vault contains them at: http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming With Kind Regards, Ovanes Markarian
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.
Boost Vault contains them at: http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming
With Kind Regards,
Ovanes Markarian
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
A project at http://saga.cct.lsu.edu uses future objects for every api call of the interface. Works for us fine. Also, we added some concept of || and && with futures for waiting concepts.
"Ovanes Markarian"
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 have an incomplete prototype of the futures and thread pools from N2276. I intend to add it to boost.thread once the move to subversion is complete, and adjust it in line with whatever the C++ committee approve. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
On Wednesday 25 July 2007 11:17, Ovanes Markarian wrote:
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.
Boost Vault contains them at: http://boost-consulting.com/vault/index.php?&direction=0&order=&director y=Concurrent%20Programming
Braddock Gaskill also was working on an end-all-beat-all futures implementation: http://www.braddock.com/~braddock/future/ It was discussed on this list back in March. My active object library libpoet also has a promise/future implementation, and I know there is a future class in ACE. -- Frank
Ovanes Markarian wrote:
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.
Boost Vault contains them at: http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming
There's another (very rough) implementation of futures here: http://www.mr-edd.co.uk/?p=56 (code download at the end of the post). http://www.mr-edd.co.uk/?p=54 (design and implementation details for my futures). It doesn't match the futures proposed for standardisation, but there is a large amount of overlap in terms of functionality. Perhaps it goes some way towards a proof of concept...? I'm still plugging away at the code and have implemented a couple of additional features not mentioned in that post, including "future references" and better exception safety. I hope to post updated code over the coming weeks. Edd
Ovanes Markarian wrote:
On Wed, July 25, 2007 17:06, Andrew Holden 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
Ovanes Markarian wrote: 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
participants (6)
-
Anthony Williams -
Chris -
Edd Dawson -
Frank Mori Hess -
Kirit Sælensminde -
Ovanes Markarian