On 12/04/2016 03:56 PM, Hartmut Kaiser wrote:
I understood HPX as a library returning futures to calls to asynchronous functions, somewhat similar to std::async. In that case, the main region with all the futures would be a thread world for asynchronous. In huge applications, this does not solve the problem of organizing thousands of objects within threads. <<
Why not? You can easily (and I mean it) create asynchronous applications solely using futures for defining the necessary dependencies between tasks, running millions of tasks.
Probably because not every application is solely made of tasks. It can be made of tasks, state machines, communications, controlling of motors, using external libraries made of threads you cannot control and much more. This is what I meant about industry. I don't think one can do it only with futures created from a main which only needs to wait for the end of millions of tasks. If you disagree, it's ok for me. You just do not have the same problems to solve as I do. Great, but I offer the library for review for all those who happen to have the same problems to solve as I do.
Yes, I suppose that the whole application would be a single thread world using that analogy. Objects are not 'bound' to a particular thread, they can be accessed freely from any thread and the user is responsible for protecting them - or preferably writing functional-like code to avoid
collisions etc.
HPX uses executors to fine-control where which task is executed. Every function which (potentially) creates a new task can optionally be used with an instance of an executor (async(), future::then(), etc.)
Are we reviewing HPX? Sorry Hartmut if I gave the impression of comparing Asynchronous to HPX. IIUC it is a library written by a private company and not intended for boost inclusion. I mostly care about std::async and the proposed Standard extensions for futures. I'm not the one who brought HPX to discussion.
A future .then() or continuation is really just a type of callback too (broadly speaking).
Not really, if I understand correctly (http://en.cppreference.com/w/cpp/experimental/future/then). The functor object passed to then() is executed in an unspecified thread of execution, which makes it hard for the caller to (safely) pass data which might or might not be valid or relevant at the time the then functor executes.
By default in HPX the continuation is executed on the thread which has made the future ready.
Which would be like std::async IIUC, in which case I regret that it is not what I would want. If you again read the example (https://htmlpreview.github.io/?https://github.com/henry-ch/asynchronous/blob...), The Manager gets a new information coming from another thread. This information makes the Manager change his mind. We have at least 3 threads participating. With a continuation executed by a thread of the threadpool, reading the Manager information would be a race. Solving this problem without race and mutex is what Asynchronous provides. BTW, Asynchronous also provides continuations, future-based and most of all not future-based. There is just not one solution for every problem.
I however could not find out whether this also applied to HPX. <<
In HPX there are launch policies that can be used to control thread execution, the one that would come closest to what you are looking for would be future<thing> = hpx::async(do_something_interesting()).then(hpx::launch::sync, do_another_interesting_thing());
This tells the .then() continuation to execute the next function in the same context as the thread that completes the initial future.
Does it mean a threadpool thread or the thread which started the asynchronous task?
The thread which makes the future ready. But executors can be used to control the concrete thread (see above).
No idea what this means but I feel this might be out of scope of the discussion. Regards, Christophe
Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost