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:05:16

On 12/04/2016 04:02 PM, Hartmut Kaiser wrote:
>>>>> 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.
>>>
>>> No, you never stated that explicitly. It was my interpretation of the
>>> sentences above. Reading through the documentation etc. one might indeed
>> get
>>> the feeling that Boost.Asynchronous was designed for real-time
>> applications.
>>> Which is probably very hard to justify given the different memory
>> allocations,
>>> exceptions etc.
>>
>> It was designed for industrial applications. The real-time constraints
>> are less strict, so that the delay caused by memory allocations, thread
>> switching etc. is negligible.
>
> I still fail to see the connection between industrial applications and the
> absolute need to use Boost.Asynchronous. Can you elaborate please? The docs
> are very complicated and I have not managed to put together the full picture
> in my head.

Please do not make me say what I did not. Where did I talk about 
absolute need?
As I answered in another thread, let me quote:
"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 kind of application is made of a great number of different aspects. 
One does not even get to control all of them as a fair number of 
external libraries is used which themselves use their own thread to call 
a callback.
Parallelization is an aspect, which Asynchronous manages quite well (see 
Boost.Sort mini review), but there are more.
Writing thread-safe code with all these aspects is a challenge.
Worst, such applications imply a huge cost when they fail. Stopping a 
production line is a disaster. No client will be happy to know that the 
software produced a core file but it's great because developers can fix 
their race.
So, how do we solve this? It turns out that good testing (unit, 
regression, and good old testers) will find most "normal" bugs but no 
good testing finds all races. Actively avoiding races by 
compartmentalizing code into thread worlds with safe callbacks go a long 
way. Communicating between worlds or with external libraries can be made 
with make_safe_callback as in this example of a classical layered 
application 
(https://htmlpreview.github.io/?https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/doc/asynchronous.html#d0e6470).

>>>> 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.
>>>
>>> So we are speaking about soft realtime here, with a focus on high
>> throughput,
>>> correct? That makes more sense and is more aligned with the research I
>> am
>>> aware of about multi-core real time systems. For a moment, I was hoping
>> you
>>> found a way to solve that problem, which would have been awesome.
>>
>> Sorry, no ;-)
>> Its focus is on soft real-time, though as written above, the hard
>> real-time constraints necessary for a production line are easily
>> achievable. All one needs is defining high priority for urgent events.
>> The reaction time is then the longest task a scheduler has to execute
>> with a lesser priority.
>> Taking as an example an object reacting to events and executing no long
>> task, living withing a scheduler with 2 queues, one low prio and one
>> high prio, if a timer event is sent to the high prio queue, the max.
>> reaction time is the task currently executing on this scheduler + one
>> context switch. Not perfect real-time but good enough for many needs.
>
> IIUC, this means that Boost.Asynchronous provides no real-time guarantees at
> all but relies on the programmer to make sure that no long-running tasks are
> active. Is that correct?

Again, yes. The aim of the library is that users write short tasks in 
the single thread worlds and use threadpools for long tasks.
The library also provides very good diagnostics 
(https://htmlpreview.github.io/?https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/doc/asynchronous.html#html_diags) 
to detect long tasks. Developers are surprisingly bad at guessing where 
their code is slow, so it is very helpful.

Regards,
Christophe

> Regards Hartmut
> ---------------
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>