Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » eTrice » message priority
message priority [message #968739] Fri, 02 November 2012 18:11 Go to next message
Tim Born is currently offline Tim BornFriend
Messages: 15
Registered: October 2012
Junior Member
I'm not throwing rocks here, just trying to understand what is and isn't in eTrice. I'm quite fond of eTrice already, but I need to know the edge conditions of my tools.

ROOM recognizes messages may have different priorities. The eTrice eclipse help file even mentions it, but that seems to be the last mention of "priority". I went looking through the code. In org.eclipse.etrice.runtime.java.messaging there is mention of priority, but that looks like thread priority, not message priority. Scanning the Java generated from a ROOM file I see the message sending that is generated, but nothing that indicates a way to set a message priority.

Am I correct that message priority is not part of eTrice 0.2.0?

thanks,
-tim
Re: message priority [message #969994 is a reply to message #968739] Sat, 03 November 2012 18:51 Go to previous messageGo to next message
Thomas Jung is currently offline Thomas JungFriend
Messages: 12
Registered: February 2011
Junior Member
Hi Tim,

you are right, message priorities are currently not implemented in eTrice 0.2.
Also threading is currently implemented in the Java runtime, not in the C runtime.

In the eTrice version 0.3 (see project plan on the project page) there will be threading for C but probably no message priorities.

However, we know that we need message priorities in our final solution.
What we plan to do is to develop a physical model which describes nodes and processes and communication channels between address spaces (an address space is currently a subsystem in eTrice). A mapping model will be responsible to deploy Aktors on nodes, processes and threads. Beside the OS specific code all the communication code will be generated out of this models. The current modeling of thread deployment is an interim solution.

Once we have the physical model we will implement all runtime features, including message priorities.

Anyway, if message prios is a killing feature for you i am sure we could implement at least the prios in the grammar so that you get access in the code generator. From this point you could implement the prios in the runtime and the code generator by yourself.

How important are message Prios for you? How many prios would you prefere? Would you spend a separate queue for each priority (footprint vs. performance)?
What is your opinion?
Re: message priority [message #982109 is a reply to message #969994] Mon, 12 November 2012 23:48 Go to previous messageGo to next message
Tim Born is currently offline Tim BornFriend
Messages: 15
Registered: October 2012
Junior Member
Thank you for your thoughtful response. No, message priority is not a killer issue at this point, so I would not suggest changing your plans. I was just trying to make sure it was really missing and I had not overlooked it.

The description of building the deployment view (physical model) sounds great! I was wondering why there was that extra subsystem layer in there. Now it makes sense.

cheers,
-tim
Re: message priority [message #985136 is a reply to message #982109] Thu, 15 November 2012 07:17 Go to previous message
Thomas Schuetz is currently offline Thomas SchuetzFriend
Messages: 31
Registered: January 2010
Member
the next steps:

We just started the implementation of the first version of the physical model and the mapping model.
This version will only provide the definition of node classes and instances with physical threads (queue prios, stacksize, queue dimensions, ...).
Mapping:
LogicalModel -> PhysicalModel {
SubSystem -> Node {
LogicalThread -> PhysicalThread
...
}
}

The independent mapping model enables n:m mappings between logical and physical models (e.g. one for simulation, one fore the target, one for debugging ...).
In later version we want to provide connections between nodes, that implement communication between Subsystems.


Thomas
Previous Topic:importing an actor reference
Next Topic:replicated ports
Goto Forum:
  


Current Time: Wed Apr 24 18:18:28 GMT 2024

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

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

Back to the top