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