Re: [boost] Asynchronous library now in Boost Library Incubator

Subject: Re: [boost] Asynchronous library now in Boost Library Incubator
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2016-12-04 17:06:33

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/master/libs/asynchronous/doc/asynchronous.html#d0e6437), 
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
>