| All,
Øyvind and I had an exchange off line, and I think I see where a mis-communication creeps in. Øyvind said
====== Perhaps you mean that a subset of occam would be needed to get meaningful cycle count? That occam as it is won’t give us this now. I believe that the XMOS architecture takes it further. Is XC a subset of occam on the transputer? ======
What I am getting at would take it either way - could be interpreted as a subset of occam (i.e. occam + restrictions) or something that takes occam further. I have actually used this successfully and thought it rather obvious.
What takes occam further is occam + Transputer priority, and the subset of occam in question is the high-priority subset of occam, with the restriction that each high-priority process is restricted to a known maximum cycle count before it deschedules. In addition there must be a round-robin scheduler. The consequence of this is that wait time before response of a high-priority process (when ready) is less than the sum of the maxima for all the high-priority processes (you can subtract the time of the responding process itself). In the case of an ALT, this would hold for a unique winner, because output is ready and the communication on the ALT side after disabling will therefore be immediate with no descheduling. IT DOES NOT MATTER IF THE OTHER SIDE OF THE COMMUNICATION IS LOW PRIORITY, though the low-priority process’s response to the communication might be delayed if other high-priority processes “spin” to the exclusion of low priority. So to make it robust against that, you have to impose a maximum cycle count before high priority becomes dependent on low priority, and enforce spacing of external stimuli. (I have a US-only patent that deals with stuff like that, which Øyvind says I should not be ashamed to mention!)
This is all standard interrupt stuff, done ad hoc on other processors. The provable result is due to the beautiful design of the Transputer, which must (and, at the bare metal, can) be emulated on other processors to get the result. This does not so much have to do with CSP, I am learning, as it operates on a kind of sub-CSP level.
Larry
All (+ Peter Morris)
All,
In [2], Peter Morris says,
And once one has implemented CSP channels, one can implement ALTs by polling ready flags in the channels.
Does “polling" mean what it customarily means, trying again and again until an OK is found? If so, I would disagree that the described approach is a substitute for occam ALT, which does not poll.
In the context of «timing analysis» I don’t think he would have thought of busy polling. I have added Peter Morris on the list. Peter, are you there? Øyvind Therefore, I disagree that an “occam Ravenscar” profile is superfluous. However, for schedulability it must be occam + priority. Given absolute high priority as found on the Transputer, and cycle-counted limits on high-priority code between deschedulings, a round-robin scheduler can guarantee response within a known count of cycles.
It’s either one or the other, isn’t it: 1.) occam Ravenscar or 2.) schedulability analysis and guaranteed response time? Or is there a possibility of both in a case? Øyvind Larry
All The Ravenscar profile is for safety critical systems written in Ada. It basically takes the rendezvous away. This opens for schedulability analysis. [1] I have wondered about this in [2] (the “Computer scientist” quoted is close to the Ravenscar profile..) Finally I now have had a mail with Roger Shepherd how the transputer tackled this, whether there also would be any reason to make an “occam Ravenscar” profile. From what he answered I think the answer is no. [3] Any comments welcomed. Please state if your comment here might by name be quoted in the blog note. If I don’t see this specifically I will not do any copy paste. (But I will not guarantee that I might not mail you and ask in case I think you may have forgotten…) For any one of you who are extremely knowledgable about the XMOS processors and XC I would be delighted to see this viewed also from that perspective.. Med vennlig hilsen / Best regards Øyvind Teig Pensioner and blogger from June 2017
http://www.teigfam.net/oyvind/home/technology/ Senior utviklingsingeniør, siv.ing. / Senior Development Engineer, M.Sc.
Autronica Fire and Security AS
Research and Development UTC Building and Industrial Systems Phone: +47 95961506
E-mail: oyvind.teig@xxxxxxxxxxxxxxxx, web: www.autronicafire.no
<image001.jpg>
|