Well, not expected that it really works out, I was very impressed: 1500 lines of code of the state machine engine made it possible to replace all (around 20) hand crafted switch/case based state machines in one of the asynchronous frameworks I am working at. The state machines are specified by a syntax directly reflecting the UML state chart terminology, making the state machines much more transparent and extensible.
Yet, the state machine module is not finalized: missing are history feature and a proper documentation. If you know UML state charts and would like to try it out, please drop me a note.
But that’s not actually what I wanted to write about today. As the title implies, this post is more about object orientation and object models.
If you’ve followed my previous blogs, I invested a lot of time in creating a Pi-Calculus message communication system, which is now used for one of my distributed applications. But my self-criticism forced me to reverify the semantics and associated guarantees to see if this system is capable to satisfy the requirements of my proposed 3D visualization system. And sadly, this evaluation forced me back to the drawing board.
Drawing and writing a lot of text to balance out all options, I came up with some conclusions:
1. A messaging system’s semantics, even if asynchronous must behave similar to a call stack.
2. A messaging system shall not depend on the objects forming the actors, and shall not affect their lifetime.
3. Signalling and receiving signals (slots) must be separated.
4. A messaging system in a high performance environment shall reduce the number of memory allocations on the heap to a minimum.
The rationale behind:
1. Messages in the Pi-Calculus may deliver message ports, where clients may sent messages through. This is like moving the ends of a wire through another wire. If such a message port is sent over some other and the client immediately sends a messages at this port afterwards, the second message may never find its way to its destination. For example:
a. message is sent to a factory which is creating a Button UI object.
b. message is sent to the Button UI object to change its text.
Here, if the factory may forward the first message (message c), the message queue would change to:
a. b. c.
which implies, that message b is delivered before message c. But at the time we deliver message b, the Button UI object is not existing yet, and so the message is not delivered and gets ignored.
So, what we really expect is that the forwarding step is scheduled before message b.
2. Lifetime is somewhat related to the messaging system. Especially when it comes to resource sharing or object dependencies. But from my previous experience I chose not to connect the lifetime of actors with the message delivery. The C++ operators new and delete shall be used like one would expect, making lifetime issues and ownership more transparent. Of course, the messaging subsystem is required to be able to handle all the situations which may arise. This implies being able to deliver messages even if the object is deleted in a transaction and sending messages to multiple objects even if they vanish while the delivery is processed. All of the related problems finally found a solution and so I decided not to patronize developers in terms of memory management.
3. At first, separating ports into signals and slot was merely a step to make the code more obvious. But then, I realized that the requirements for them were – of course – different, leading to a cleaner internal design.
4. Avoiding heap allocations is not possible when looking at the required flexibility and associated constraints, but there is a huge potential in reusing previously allocated message and channel objects. So reducing the the number of memory allocations while runtime to near zero should be possible.
This second version of a messaging system is probably the basis for a total decoupling of objects, which is – in my opinion – the only feasible concept to create a stable environment for a 3D visualization system.
maximize contact, minimize constraints!!!