Enclaved execution

[erlingrj]

To enable experimentation with real-time scheduling in reactor-uc, I am looking into enclaved execution. We discussed it at the meeting yesterday and we came to a couple of conclusions:

1. To maintain consistency, we will have similar rules for enclaves as for federates. Meaning that if a reactor is enclaved, then all the top-level reactors within it are enclaves. So for a normal enclaved program we would write:

enclaved reactor {
  r1 = new R()
  r2 = new R()
}

Just like federated reactor.

Like for federated, the enclaved reactor can not have any reactions inside it, only the enclaves.

2. A federate can also be enclaved. This is specified with an attribute. An enclaved federate will have all its top-level reactors as enclaves.

federated reactor {
  @enclaved
  f1 = new Fed()
  
  f2 = new Fed()
  
  @enclaved
  f3 = new Fed()
}

3. Enclaves can thus not communicate directly with enclaves in other federates. It must happen through the ports of the federate.

[tanneberger]

I think it's worth saying that 1.) and 2.) are compatible.

Then you can write enclaved reactors that are always enclaved, or alternatively you can annotate a reactor with @enclaved to make it an enclave in that particular deployment.

[erlingrj]

After some more exploration, I have concluded that it is better to NOT support annotating a reactor instance as enclaved, instead we should require that reactor declarations are annotated as being enslaved. This is much more aligned with how the code-generation works today. The reason is that we would like to code-generate structures and code based on reactor-definitions, and then instantiate those reactors. I think you can create the same type of enclaved programs, but you might have to make "intermediate" enclaved reactors if you want a reactor to appear as both enclaved and not enclaved.