|Discussion Multithreading [message #656092]
||Thu, 24 February 2011 02:39
| Thomas Schuetz
Registered: January 2010
Problem: Initial Transition of FSMs is executed in main Thread, but should be executed in the assigned thread.|
Proposal of Thomas Jung: on call of Actor::start(), the actor sends himself the init message.
atm the Actor has no system (debug...) port and we can not use a user defined port. So we should think about implementing the system port first - we need it anyway for the debugging infrastructure.
What do you think?
The instance path is used atm for debugging and registering IOs. We definitely need a threadsafe implementation. Using the Instance Path is a very convenient way to register an SAP. For the MSC logging it will not be used in the future since we will log only the pure message and generate a converter that maps the addresses to names an generates an MSC.
We will not create a built in instance configuration mechanism like in Trice, since we saw that there are very different requirements and ways to do that. Instead we have the Layering (SAP/SPP) mechanism, so everybody can build his own mechanism. I would deliver an example implementation as Service in the modellib, like the timeout.
|Re: Discussion Multithreading [message #656131 is a reply to message #656096]
||Thu, 24 February 2011 05:15
| Henrik Rentz-Reichert
Registered: July 2009
thanks for investigating this - even with an implementation already!
In the former Trice we used the MessageReceiver interface of the Actor
directly for the purpose of system messages (e.g. to toggle tracing).
This means that we had receive(Message msg) for system messages and
receiveEvent(InterfaceItemBase ifitem, int evt, Object... data) for
model messages. This worked quite well and looks similar to what you
If, on the other hand, we would equip the ActorClassBase with a reserved
system port which can not be seen by the model we have the advantage
that we can define the protocol and behavior in the ROOM language. We
would generate the code and move it to the modelbase package of the
runtime. The ActorClassBase would implement the receiveEvent method and
handle messages from the system port (using generated code). The method
should return a boolean indicating whether the event was handled or not.
At the same time we would remove the MessageReceiver interface from the
The generated code will have to call super first in the receiveEvent
method and return instantly if that returns true.
The system ports of all actors could on the other hand be connected with
a (sub)system wide (replicated) actor debug port which is used for
tracing, message injection and data inspection and manipulation.
The advantage of this bootstrapping method is of course that we can
model and generate also the system level protocol and behavior - even if
we have to move the code manually to the runtime library.
Am 24.02.2011 09:21, schrieb firstname.lastname@example.org:
> I already have a running implementation for the threadsafe init
> transition (currently just in the generated code from a testmodel).
> What i did is simply using the receive method from the actor instead of
> the receiveEvent. The receiveEvent will be called from the user defined
> Port. The receive method can be seen as an actor "internal" port (may be
> port is not the right term).
> So, i registered the actor itself as a message receiver at his own
> message service. Therefore the mesages for the actor itself uses the
> same communication infrastructure as the user defined ports. With the
> actor id it is possible to directly address the actor itself (which is
> already implemented in the dispatcher).
> Within the start method the actor send the init message via its own
> message service to themself. The only thing i am missing is a dedicated
> internal message. And this was allready anwered from Henrik yesterday.
> What i am thinking about is, where to implement the receive and/or start
> There are large invariant protions in all envolved methods so that it
> makes sence to put almost everything in the ActorClassBase. But this
> implies that everybody inherits this common behaviour (also the services
> e.g. timing). For the initial transition this is ok but the question is,
> will we get later on specialized actor implementations for spezial
> My proposal is to put it in the Base class and make some expirences with
> I can deliver my implementation as discussion base.
> What do you think?
Powered by FUDForum
. Page generated in 0.03110 seconds