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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk