|
|
| Re: Discussion Multithreading [message #656131 is a reply to message #656096] |
Thu, 24 February 2011 10:15   |
 Henrik Rentz-Reichert
Messages: 261
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
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.03621 seconds
] 
Search
Help
Register
Login
Home
