On Fri, Mar 7, 2014, at 05:59 AM, Michael Haberler wrote: > John, > > > thanks for going through this. I think we have reached clarification of a > not-so-well understood corner of HAL which was unclear to some (well at least > me). > > Can I summarize what I read from the above as follows: > > - there are two pieces of state (addval and deltalim) passed from servo to > base in stepgen.c
You wrote that there were two pieces of state passed from servo to base. The actual stepgen structure contains 38 members. Of those, 9 are labeled as being both read and written by make_pulses, and 11 are labeled as being read but not written by make_pulses. Unfortunately, the comments don't say which ones are read/written by the two slow functions. I have not done the code audit needed to be sure if the two you mentioned are actually the only two of interest. > - for correctness of stepgen operation it is not essential these values > origin from the same invocation of update-freq, meaning make-pulses is not a > critical region with respect to access of these values Agreed. > - as a consequence, the threads executing update-freq and make-pulses are not > subject to any priority and non-preemption preconditions Not so. Just because addval and deltalim are independent does not mean that no concurrency risks exist. I pointed out in my analysis that deltalim is accessed multiple times during one invocation of make_pulses. If it is possible for update_freq to run concurrently with or interrupt make_pulses, then deltalim should be copied to a local and subsequent accesses should use the local copy. This is a simple fix, but until it is done, update_freq and make_pulses ARE subject to priority and/or non-preemption conditions. Also, I suspect that deltalim is not the only variable that needs such treatement. > does this reflect our common understanding? I still assert that since the code was written assuming that the fast function could not be interrupted, a careful code audit is neeeded before we make any changes to the scheduling system. I understand that if "make_pulses" is moved to the PRU, then the existing assumptions become invalid. But Charles's PRU code is only loosly based on the existing make_pulses. When I wrote make_pulses, I was operating under the assumption that it would not be interrupted. Therefore it needs to be audited before we break that assumption and allow it to be interrupted. When Charles wrote his code he was aware that the PRU and the servo thread could run concurrently, and therefore (I assume) he made sure it would work correctly in that situation. I have not yet heard a persuasive arguement as to why we want to change the scheduling system for ordinary (non-PRU, non-FPGA) systems. Today, we run all RT code on one core, and we use priorities to keep the slow code from running during the fast code. What are the percieved benefits of changing that? Are those benefits worth the effort of doing code audits on stepgen, pwmgen, encoder, etc.? -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
