Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » eTrice » Discussion Multithreading(Issues regarding the Introduction of Multithreading inside SubSystems)
Discussion Multithreading [message #656092] Thu, 24 February 2011 07:39 Go to next message
Thomas Schuetz is currently offline Thomas SchuetzFriend
Messages: 17
Registered: January 2010
Junior Member
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.

Thomas

Re: Discussion Multithreading [message #656096 is a reply to message #656092] Thu, 24 February 2011 08:21 Go to previous messageGo to next message
Thomas Jung is currently offline Thomas JungFriend
Messages: 12
Registered: February 2011
Junior Member
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 method.

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 services?

My proposal is to put it in the Base class and make some expirences with that.

I can deliver my implementation as discussion base.
What do you think?
Thomas
Re: Discussion Multithreading [message #656131 is a reply to message #656096] Thu, 24 February 2011 10:15 Go to previous messageGo to next message
Henrik Rentz-Reichert is currently offline Henrik Rentz-ReichertFriend
Messages: 220
Registered: July 2009
Senior Member
Thomas,

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
proposed.

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
ActorClassBase.
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.

-Henrik

Am 24.02.2011 09:21, schrieb thomas.jung@tieto.com:
> 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
> method.
>
> 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
> services?
>
> My proposal is to put it in the Base class and make some expirences with
> that.
>
> I can deliver my implementation as discussion base.
> What do you think?
> Thomas
>
Re: Discussion Multithreading [message #656682 is a reply to message #656092] Mon, 28 February 2011 07:15 Go to previous message
Thomas Schuetz is currently offline Thomas SchuetzFriend
Messages: 17
Registered: January 2010
Junior Member
I think we should go with Thomas' solution for the next weeks. It is already working and we can gain experience.
But before the 0.1 release we should switch to the System Port solution.
Before we have to discuss this topic in detail, since it is closely related to model level debugging.

-Thomas
Previous Topic:error message in RoomPostprocessor.ext org::eclipse::emf::ecore::EcorePackage::eINSTANCE.getEClassif
Next Topic:eTrice current status
Goto Forum:
  


Current Time: Mon Dec 22 09:22:06 GMT 2014

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

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