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