Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Generate actor system from an EMF meta-model(How to generate an "EMF aware" actor system from a meta-model ?)
| |
| Re: Generate actor system from an EMF meta-model [message #1793953 is a reply to message #1793950] |
Tue, 21 August 2018 07:13   |
 Ed Willink
Messages: 7635
Registered: July 2009 |
Senior Member |
|
|
Hi
I suspect that this isn't really an EMF question; rather a concurrent information sharing problem, for which you hope that EMF will provide a magic answer.
Bottom line: EMF is not threadsafe. But, when used sympathetically, EMF can be threadsafe.
There is an informal policy that multi-threaded EMF applications such as editors/live-validators use a ResourceSet synchronization to avoid conflict. If you can live with such coarse grained synchronization then you have no real problem.
You haven't clarified the nature of your actors, so it is unclear whether they are coarse/fine-grained and whether there are many copies of the same kind of actor or many different kinds of actor. Whatever, from an EMF point of view, the 'scheduling' is a small part of the application for which EMF provides a variety of opportunities to relate your EMFActor to your OSActor. Perhaps inheritance, perhaps delegation, perhaps synonyming via the EClass.instanceClass. You might have derived EMFDumbPollingActor, EMFSmartPollingActor, EMFMessageTriggeredActor etc EClasses to share your fundamental scheduling policies with further derived Actors. No real modeling problem. (Delegation is probably best if you want to have a diversity of OSActor.)
But actors are typically concurrent and so you can easily imagine that one actor is using one end of a bidirectional reference while another actor preempts and changes the other end causing 'confusion'. I'm not sure whether CDO of EMF Transaction can help you here. What seems certain is that without strong discipline to ensure that EMF instances are private to particular actors, you will incur significant programming difficulties and run-time overheads to impose mutexes/synchronizations. Even if you can do that, you then have the problem of 'proving' that your anarchy of synchronization will never deadlock. Rather than contributing to your solution, without sympathetic usage, EMF will amplify the underlying design problems.
There is an alternative to an arms race to synchronization dystopia; no synchronization. IFF you have design control over ALL actors that access the EMF model, you can ensure that each actor's execution is sufficiently fine grained to allow any actor execution to complete before the next (highest priority) actor executes. No pre-emption gives no thread conflicts and an opportunity for a really fast trivial scheduler without multiple stacks. IMHO the only use for multiple shared-context background thread stacks is to support a concurrent debugger thread. The 'only' problem with this approach is that you must guarantee that ALL actor execution times are sufficiently short to satisfy the FASTEST response deadline. This can be achieved by breaking slow actor executions into multiple steps; tedious and fragile to do manually, but possible if you have an abstraction from which you code generate. IMHO a small price to pay for the huge benefits of no synchronization overheads and guaranteed deadlock free.
Regards
Ed Willink
|
|
| |
| Re: Generate actor system from an EMF meta-model [message #1794001 is a reply to message #1793986] |
Wed, 22 August 2018 07:46 |
Ed Willink
Messages: 7635
Registered: July 2009 |
Senior Member |
|
|
Hi
I'm still not clear about your actors, but I'm guessing now that they come from some higher level of abstraction such as Simulink or Ptolemy diagrams.. This is good since you potentially have a sound system-level Model of Computation that enables you to decompose your system specification into sound sub-sub-sub-system (actor) specifications of communication/synchronization, security, ... You therefore 'just' need a chain of M2Ms to convert the high level abstraction to an implementation. I would certainly use EMF to ensure that everything is meta-modelled, but since you have a custom execution framework, I would almost certainly use a custom M2T for the final code generation; simple CG is really easy. If you really need some of the benefits of EMF such as XMI serialization, EMF.Edit, eClass() reflection etc, then I would look to a dual code generation, one for production without EMF support, and another for debugging with just enough EMF interface compliance to support what you need.
(It was the inadequacy of tool support for a chain of M2Ms that I encountered while collaborating on the CALtrop project with the Ptolemy guys at UCB that pushed me in my current M2M support activities. http://www.edwillink.plus.com/projects/wdl/wdl.html is an overview with many references of my vision of an actor-based MDE system.)
Regards
Ed Willink
|
|
|
| Re: Generate actor system from an EMF meta-model [message #1820820 is a reply to message #1794001] |
Wed, 29 January 2020 15:16 |
Emmanuel Chebbi
Messages: 123
Registered: February 2018 |
Senior Member |
|
|
I'd like to bring this thread back for completion purposes (for both future me and people who might stumble upon it). Since my initial post I have learned a lot about MDE & DSLs and I believe that I can now both explain the goal I had in mind and answer my own question.
So, given a model M conforming to a metamodel A, I wanted to be able to:
- use an actor system to define the semantics of A (i.e. what happens when M is executed),
- design M with an editor based on a framework like Sirius or Xtext.
I was stuck because I had the naive assumption that, in order to fulfil both wills, the semantics of A must:
- be written in Java,
- be an implementation of the interfaces generated by EMF,
which leaded to the idea of an "EMF-aware Orbit/Akka code". There are actually many better ways to define the semantics of a metamodel depending on the use case. For instance:
- if the model should be executable then the semantics can be separately specified with EMF's Switch or languages such as Kermeta or ALE,
- if the model should be embedded within an existing codebase then generating Java/Python/whatever code with Xtend can do the trick,
- if the model is not very convenient for expressing the semantics then it is also possible to create two metamodels (one defining the syntax of the editor and another one defining an executable model) and use M2M transformations to convert the first into the latter,
- etc.
In conclusion, and to answer myself, I would say that the approach depends on the requirements and that my vision of "defining an EMF meta-model describing an actor system" is a bit too vague.
Ed Willink wrote on Wed, 22 August 2018 09:46http://www.edwillink.plus.com/projects/wdl/wdl.html is an overview with many references of my vision of an actor-based MDE system.
Thank you very much for the link! I still didn't have the time to read (and understand) everything but the documents are very interesting.
|
|
|
Goto Forum:
Current Time: Sat Nov 11 09:29:01 GMT 2023
Powered by FUDForum. Page generated in 0.01315 seconds |
] 
Search
Help
Register
Login
Home
