boost::thread and boost::promise

I have some question about

Code:

---

boost::promise

---

After studying the website of boost and "C++ concurrency in action"
I still can't get the idea of

Code:

---

boost::promise

---

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

Code:

---

boost::promise

---

, could you show me an easier example of it?

Thanks a lot

Quote:

---

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.

Quote:

---

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

Code:

---

boost::promise

---

, could you show me an easier example of it?

---

See http://www.codeguru.com/forum/showthread.php?t=514204

Quote:

---

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?

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?

Quote:

---

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.

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.

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.

Hmm. I suppose I can see the value there.

Quote:

---

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.