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

Subject: Re: [boost] Asynchronous library now in Boost Library Incubator
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2016-12-04 10:02:30

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

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

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu