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-01 16:03:40

<snip>

> Thanks, this makes it a bit clearer. So essentially, a thread world, defines
> the scope of your object? Which class is modeling the concept of the thread
> world now, the scheduler? I think this information is missing from the
> documentation. Is there also a default thread world?

Definition of a thread world (which I just learned is called Appartment 
in the Microsoft world, thanks to Bjorn Reese for pointing this out):
https://htmlpreview.github.io/?https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/doc/asynchronous.html#d0e508

The scheduler is modeling the thread world in which the objects live.

There is no default thread world, one can create as many as needed.

<snip>

>>> 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.

>> 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.

The model the very fast employee of the restaurant in my introduction 
(https://htmlpreview.github.io/?https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/doc/asynchronous.html#d0e22).

Cheers,
Christophe