|
| Eric | 7. RC_Fail is possible with non-blocking semantics. (no matching request was waiting => return immediately, to be avoided as risk of busy polling) | Øyvind:
Or use an XCHAN, and you will not poll (busy or not) even in this situation. See below. [EVR>] Do you have a (distributed) implementation and formal semantics that I can take a look at?
Øyvind: No and no. But there are plans for a paper.. It looks like it may be modeled in CSP, as Peter has already modeled it in occam(pi). | Eric | Only giving priorities to messages make little sense as they don't use a lot of the processing resources, whereas Tasks/Processes do. | Øyvind:
I would regard message priority as controlling what a
process should do when, so the above argument would be invalid [EVR>] This seems to imply that receivers "pull", whereas in practice there is a partial order from sender to receiver. Priority itself is related to
the tasks's periodicity in RMA. This is a fairly objective criterium not a subjective one. The scheduleability is related to frequency and CPU load. This is quite formally developed theory. Some tasks can have a highest priority (like alarm tasks monitors)
so that they will start as soon as the event they were waiting for happens, but such tasks should actually never run unless there is a system level issue (e.g. temperature sensor reads a too high value because a valve got stuck). Øyvind: My name is Øyvind since 1.) my parents gave it to me 62 years ago and 2.) I haven’t changed it. But in other name spaces it is Oyvind or Öyvind. | Eric | I am afraid I share your wishful thinking, even if I regret so. | Øyvind
I have introduced something I call “architectural leak” in [1]: “Architectural leak” from link to application level could be seen as application code that is added to compensate for missing features at link level. Chained processes and overflow buffers are needed when buffered channels are not supplied. Busy polling is needed if the link level does not deliver appropriate flow control. The channel-readychannel connected to a buffered channel, described in this paper as x-channel, would decrease architectural leakage. So, we’re all striving for
architectural balance. So there should be balance between “I have it all already in my API” and “I want to make it all in my language”. XCHANs helps that balance! [EVR>] This is what we allow wit the hubs. The core is generic and the synchronisation predicate as well as the action predicate (implemented as call-backs)
can be modified or what we do is add hub types and theri services when an application has a vey good reason for it. Unused code is not linked in anyway. Øyvind: Could be interesting to see “XCHAN in hub” /Øyvind |