Home » Eclipse Projects » Papyrus for Real Time » Parallel / Distributed Execution
|
| Re: Parallel / Distributed Execution [message #1844843 is a reply to message #1844820] |
Mon, 27 September 2021 21:47   |
 Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
Hello, first a couple of clarifications:
PapyrusRT is based on Papyrus, but it is not the same. It implements UML-RT, including code generation and a runtime system. Papyrus implements UML, code generation is optional and has no UML runtime.
A note about terminology, to avoid confusion. In UML-RT we talk about "capsules" and "capsule instances". The difference is important. A "capsule" is a *type*, in particular, a class in the object-oriented sense, more precisely an *active* class, while a capsule *instance* is an *object* which can be thought of as the thing that "runs".
Another note about terminology: Concurrency is about allowing independent events or actions to happen without imposing a specific order, unless otherwise required by interaction. On the other hand, (true) parallelism is about executing processes in separate processors, usually with the goal of gaining in performance. So the focus of concurrency is the specification of independent activities, while the focus of parallelism is performance. Sometimes we say that capsule instances run "in parallel", but that is an abuse of terminology. We really mean that the capsule instances are concurrent.
But a concurrent system can be implemented as a parallel system: i.e. multiple logically concurrent processes could be executed by separate processors.
UML-RT supports *concurrency* but not necessarily *parallelism*. When we talk about capsule instances running in 'parallel', we mean 'concurrently'.
More specifically, in UML-RT there are two levels of concurrency: "logical threads" and "physical threads".
Logical threads represent the abstract notion of concurrency described above, while physical threads represent a concrete implementation of the concurrency model.
So, if you have a capsule C with parts "a" of type A and "b" of type B, where A and B are capsules, and A and B have their own state machines, the execution of transitions of these state machines is the interleaving (in some order) of these transitions. For example, if C has a port p, connected to both parts 'a' and 'b', while A has a transition t1: S1 --p(m)--> S2 and B has a transition t1':S1' --p(m)--> S2', and a message m arrives on port p, and a is in state S1 and b in state S1', the message is delivered to both parts 'a' and 'b', and both transitions t1 and t1' are enabled, but the order in which each is taken is not pre-determined, so the execution could be (S1,S1') --t1--> (S2,S1') --t2'--> (S2,S2'), or it could be (S1,S1') --t1'--> (S1,S2') --t1--> (S1',S2'). This is "logical" concurrency.
But then there is the "physical" concurrency which is how this logical concurrency is implemented. This implementation is the runtime system (RTS for short). In the RTS, when the system runs, there are several "controllers". Each controller runs in its own OS thread (this is what we call a "physical" thread). Every capsule *instance* is allocated to "run" in a controller. The controller has a message queue, shared by all capsule instances under its control. When a message is sent to a capsule instance, it goes to its controller's queue. The controller runs a loop taking the first message (according to priority) from the queue, and delivers it to the capsule instance, which then performs a run-to-completion step of the relevant transition, and when it reaches a stable state, control goes back to the controller and the controller continues with the next message in the queue. This is quite different than the way other similar languages like the Actor model work, where the equivalent of capsules or ports have their own queues. You can think of capsules in a controller as "green threads", if you are familiar with the term.
By default, there is only one controller, and therefore only one OS thread, executing all capsules. But you can specify multiple controllers and allocate capsules to them. There are two ways of doing this.
The first is that you create a plain text file called "Top.controllers" consisting of lines of the form
<capsule-part-fully-qualified-name> = <controller-name>
So for example, if you have capsule Top with part a of type capsule A which in turn has a part b (inside A) of type Capsule B, you could write
Top = TopController
Top.a = Controller1
Top.A.b = Controller2
This will automatically create three controllers and assign each capsule instance to the corresponding controller.
Furthermore, if a part is replicated, by default, all its instances will go to the same controller, but you can specify alternatives for each slot. For example, if b has replication 2, you can have
Top = TopController
Top.a = Controller1
Top.A.b[0] = Controller2
Top.A.b[1] = Controller3
The second way of assigning capsule instances to controllers is via the "incarnate" operation. This is applicable only to "optional" parts. In this case, the "incarnate" operation takes as arguments thepart, the type of the capsule to incarnate and a pointer to the controller instance. The name of the C++ pointer variable for a controller is the same as the one specified in the Top.controllers file. So, for example, if in the above, there has an optional part d of type D inside capsule A, any action code in A's state machine could have the following action:
frame.incarnate(d, &D, &Controller2);
where 'frame' is a port of the built-in "Frame" protocol (which you can add from the Model Explorer).
Finally, if you don't specify the controller for a given part, it will be allocated to the same controller as its container capsule instance.
Now, controllers could potentially be run in separate cores, or even separate processors, to achieve true parallelism but this is not supported by the PapyrusRT RTS. Of course, nothing prevents you from manually launching processes in separate cores or processors from within the action code of a capsule, but that would be entirely your responsibility on how to manage them, and the RTS would not know anything about them.
As for the distributed implementation you mentioned, I haven't tried it, but Karim (who made it) has shown me demos, and it is quite promising. Any questions on it should be addressed to him. I don't know if he reads this forum, but if not, you can try contacting him.
|
|
| | |
Goto Forum:
Current Time: Mon Sep 09 08:40:05 GMT 2024
Powered by FUDForum. Page generated in 0.03456 seconds |
] 
Search
Help
Register
Login
Home
