-
November 14th, 2011, 11:33 AM
#1
boost::thread and boost::promise
I have some question about After studying the website of boost and "C++ concurrency in action"
I still can't get the idea of According to the book(if I have no make any mistake)
boost::future is designed for one off event
you could wrap the task by packaged_task and let boost::unique_future
to gain the result of the task. When you launch the thread, you could
just return the boost::unique_future and wait for the result of the task.
After the task is finish, you could continue your job.
It is very like boost::condition_variable but design for one off event.
Do I make any mistake about it?
Assume that I didn't make any mistake about the idea of future, I still can't
get the idea of , could you show me an easier example of it?
Thanks a lot
-
November 14th, 2011, 02:43 PM
#2
Re: boost::thread and boost::promise
Originally Posted by stereoMatching
According to the book(if I have no make any mistake)
boost::future is designed for one off event
you could wrap the task by packaged_task and let boost::unique_future
to gain the result of the task. When you launch the thread, you could
just return the boost::unique_future and wait for the result of the task.
After the task is finish, you could continue your job.
It is very like boost::condition_variable but design for one off event.
Do I make any mistake about it?
The difference between a future and a condition variable is that a future is a pull-driven mechanism and a condition variable is a push-driven mechanism. When you ask the value of a future, the call waits until the value of the future is set (from another thread). If the value was already set before the call, the function returns immediately. With a condition variable, you wait until it is notified. Whether a condition variable was notified before you call wait on it has no influence; you'll wait until it is notified again.
Originally Posted by stereoMatching
Assume that I didn't make any mistake about the idea of future, I still can't
get the idea of , could you show me an easier example of it?
See http://www.codeguru.com/forum/showthread.php?t=514204
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
-
November 14th, 2011, 07:19 PM
#3
Re: boost::thread and boost::promise
With a condition variable, you wait until it is notified. Whether a condition variable was notified before you call wait on it has no influence; you'll wait until it is notified again.
Thanks, looks like I make a mistake again, that means we have to design carefully to make sure
the condition_variable would be notify?
-
November 15th, 2011, 11:16 AM
#4
Re: boost::thread and boost::promise
I've always been a bit hazy about futures and promises too. Let me see if I have a handle on it now.
It seems to me that it is similar to the thread-pool pattern, in that if a packaged_task is sent to a worker thread to be executed, then the future is the handle which can be used to retrieve the result.
How does a promise fit into this framework?
-
November 15th, 2011, 01:16 PM
#5
Re: boost::thread and boost::promise
Originally Posted by Lindley
How does a promise fit into this framework?
promise<T> is the provider of future<T>; the promise is managed by the "worker" thread, that sets its value or its exception; the future is managed by the "boss" thread that waits for the value (or the exception) of the future to be set.
from another POV, you can see them as "splitting" a value T into its two asynchronous parts: set (=promise<T>) and retrieval(=future<T>); in this sense the framework exhausts with promises and futures.
for example, the "asynchronous version" of
Code:
int main()
{
int some_int = 42;
std::cout << some_int << std::endl;
}
is
Code:
int main()
{
std::promise<int> int_promise;
std::future<int> future_int = int_promise.get_future();
std::thread worker( [&]{ int_promise.set_value( 42 ); } );
std::cout << future_int.get() << std::endl;
worker.join();
}
finally, packaged tasks are just helpers used to automate the creation of the promise associated to the return value of an asynchronous task.
-
November 15th, 2011, 01:39 PM
#6
Re: boost::thread and boost::promise
Hmm. I suppose there's some value in creating those "primitives", but they seem fairly meaningless outside of the thread-pool pattern usage so far. Perhaps I just haven't encountered the right scenario to require them.
-
November 15th, 2011, 03:31 PM
#7
Re: boost::thread and boost::promise
well, they are useful whenever you have an asynchronous call, with the benefit of having a uniform interface supporting, among other things, exception handling in a natural way. For example, suppose you are developing a library implementing, say, an actor model with asynchronous messages/actions; with futures ( and promises, hidden behind some call mechanism ) you can return a value to user code with asynchronous semantics in a way he can understand, indipendently of the specific library interface, in a generic way; this is valuable, I think.
-
November 15th, 2011, 03:35 PM
#8
Re: boost::thread and boost::promise
Hmm. I suppose I can see the value there.
-
November 15th, 2011, 09:02 PM
#9
Re: boost::thread and boost::promise
Originally Posted by Lindley
Hmm. I suppose there's some value in creating those "primitives", but they seem fairly meaningless outside of the thread-pool pattern usage so far. Perhaps I just haven't encountered the right scenario to require them.
What a frustrating and discouraging comment. It's lucky of me that I am in a good mood, otherwise I'll get mad about this. How about a broken promise ?
You mark them as Async then export them as a service and call them in your C/C++ code.
hi,,,
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|