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-11-30 14:31:58

On 11/29/2016 09:40 PM, Thomas Heller wrote:
> On Dienstag, 29. November 2016 20:41:58 CET Christophe Henry wrote:
>>> boost.asynchronous looks to have many of the same features/functionality
>>
>> as HPX.
>>
>>> Can I ask why you chose to reimplement futures/lightweight thread
>>
>> pools/parallel STL/etc,
>>
>>> rather than working on improving HPX to suit your needs?
>>
>> I don't think the libraries have the same goals (or at least it seems to me
>> so). Asynchronous is first of all an architecture tool focusing on
>> organizing a whole application into thread worlds.
>
> Can you please elaborate a little on what is meant with "thread worlds"?

You might want to read the concepts parts.
I'll elaborate a little more. I will also add more to the doc.
A "thread world" is a world defined by a (single threaded) scheduler and 
all the objects which have been created, are living and destroyed within 
this context.
It is usually agreed on that objects and threads do not mix well. Class 
diagrams fail to display both as these are orthogonal concepts.
Asynchronous solves this by organizing objects into worlds, each living 
within a thread. This way, life cycles issues and the question of thread 
access to objects is solved.
It is similar to the Active Object pattern, but with n Objects living 
within a thread.

>>
>> The libraries also do not have the same design / tradeoffs. Asynchronous
>> can make use of futures but encourages callbacks and tries to make these as
>> safe as possible. The goal is to be as asynchronous (meaning non-blocking)
>> as possible.
>> It is no coincidence that I'm also the author of Boost.MSM. The encouraged
>> design is a whole lot of state machines, each in its own thread (possibly
>> sharing a thread), sending tasks to threadpools, TCP connections, etc. and
>> waiting for callbacks. Future-based designs do not mix well with state
>> machines' run-to-completion.
>>
>> The reason for the non-blocking focus is that I'm using the library at work
>> in an industrial 24/7 application. When working on the production line,
>> blocking is a disaster. If an algorithm goes astray, or simply takes longer
>> than usually, blocking the production line results in huge costs. Crashes
>> due to races also. Asynchronous provides ways to avoid both.
>
> Does this mean that Boost.Asynchronous provides realtime worst case execution
> time guarantees?

I did not state this. This is not a real-time library.
However what the library offers might or might not be sufficient for 
your needs. Automotive usually has more stringent needs as other industries.
A way to handle hard real-time (meaning an answer has to be given latest 
at a precise time),  is to write manager objects like state machines (no 
matter real state machines or own implementation) living within a thread 
world and reacting to events. A timer event would be one of them. When 
the event is emitted, the manager can react. The library ensures 
communication between worlds using queues with different priority. 
Giving the highest priority to the timer event will ensure it will be 
handled next. In theory a run to completion executes in 0 time unit. But 
as this is never the case, there is a delay due to user code and thread 
context switching, so it is not a perfect hard real-time.
To help with soft real-time (throughput), the library provides 
threadpools and parallelization mechanisms.

Christophe