<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... 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...). Cheers, Christophe