On Mittwoch, 30. November 2016 20:31:58 CET Christophe Henry wrote:
On 11/29/2016 09:40 PM, Thomas Heller wrote:
On Dienstag, 29. November 2016 20:41:58 CET Christophe Henry wrote:
boost.asynchronous looks to have many of the same features/functionality
as HPX.
Can I ask why you chose to reimplement futures/lightweight thread
pools/parallel STL/etc,
rather than working on improving HPX to suit your needs?
I don't think the libraries have the same goals (or at least it seems to me so). Asynchronous is first of all an architecture tool focusing on organizing a whole application into thread worlds.
Can you please elaborate a little on what is meant with "thread worlds"?
You might want to read the concepts parts. I'll elaborate a little more. I will also add more to the doc. A "thread world" is a world defined by a (single threaded) scheduler and all the objects which have been created, are living and destroyed within this context. It is usually agreed on that objects and threads do not mix well. Class diagrams fail to display both as these are orthogonal concepts. Asynchronous solves this by organizing objects into worlds, each living within a thread. This way, life cycles issues and the question of thread access to objects is solved. It is similar to the Active Object pattern, but with n Objects living within a thread.
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?
The libraries also do not have the same design / tradeoffs. Asynchronous can make use of futures but encourages callbacks and tries to make these as safe as possible. The goal is to be as asynchronous (meaning non-blocking) as possible. It is no coincidence that I'm also the author of Boost.MSM. The encouraged design is a whole lot of state machines, each in its own thread (possibly sharing a thread), sending tasks to threadpools, TCP connections, etc. and waiting for callbacks. Future-based designs do not mix well with state machines' run-to-completion.
The reason for the non-blocking focus is that I'm using the library at work in an industrial 24/7 application. When working on the production line, blocking is a disaster. If an algorithm goes astray, or simply takes longer than usually, blocking the production line results in huge costs. Crashes due to races also. Asynchronous provides ways to avoid both.
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.
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.
Christophe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost