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
> > the feeling that Boost.Asynchronous was designed for real-time
> > Which is probably very hard to justify given the different memory
> > 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
> >> 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
> >> world and reacting to events. A timer event would be one of them. When
> >> 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.
> >> 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
> > correct? That makes more sense and is more aligned with the research I
> > aware of about multi-core real time systems. For a moment, I was hoping
> > 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk