Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Papyrus for Real Time » Parallel / Distributed Execution
Parallel / Distributed Execution [message #1844820] Mon, 27 September 2021 08:18 Go to next message
Zoltan Szocs is currently offline Zoltan SzocsFriend
Messages: 2
Registered: September 2021
Junior Member
Hi All!

I am new to Papyrus, and I would need some help on how parallel processing works.

I understood from the documentation (can't find now where), that the capsules are being executed in parallel. I created a sample application, but I couldn't prove it: If I added sleep commands to certain parts of the code, everything stopped.

Also, I wanted to try out distributed execution of the generated application. I have found a plugin which promises exactly that ( However, after installing this plugin I can no longer open old projects or create new Papyrus-RT projects.

Any help would be appreciated!


Re: Parallel / Distributed Execution [message #1844843 is a reply to message #1844820] Mon, 27 September 2021 21:47 Go to previous messageGo to next message
Ernesto Posse is currently offline Ernesto PosseFriend
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.

Re: Parallel / Distributed Execution [message #1844934 is a reply to message #1844843] Thu, 30 September 2021 05:08 Go to previous messageGo to next message
Zoltan Szocs is currently offline Zoltan SzocsFriend
Messages: 2
Registered: September 2021
Junior Member
Thank you for this super-detailed answer!
The idea of controllers in Papyrus-RT is new for me.
Is this available somewhere in the documentation?
I am asking just to know if there are some pages I missed or it is just not that well documented.
Re: Parallel / Distributed Execution [message #1844960 is a reply to message #1844934] Thu, 30 September 2021 21:57 Go to previous message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 438
Registered: March 2011
Senior Member
Were you looking at the wiki at or somewhere else?

I don't think the wiki has info on this.

But the description of controllers can be found in the ROOM book. UML-RT is nothing but a UML profile of the ROOM language (Real-time Object-Oriented Modeling). That book is the ultimate reference for its semantics.

If you are interested in a formal semantics for it, I wrote a paper on this a few years ago: An executable formal semantics for UML-RT. It discusses controllers at length and how controller assignment affects behaviour.
Previous Topic:Boolean array in Papyrusrt
Next Topic:DC motor fails to start/stop - Papyrus-RT model
Goto Forum:

Current Time: Fri Feb 23 04:02:45 GMT 2024

Powered by FUDForum. Page generated in 0.02886 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top