On Tue, Mar 4, 2014, at 04:08 PM, Michael Haberler wrote: > ok, let's move further. I feel we are converging on the following aspects: > > 1. a key issue is the atomic passing of multiple values between threads (all > or none) > 2. one way to ascertain this is the current method, which in effect makes one > thread a critical region by making it non-preemptable by the other thread > through means of higher priority *) > > I think the following is the key question (again this is correctness related > only, performance is not relevant for the answer):
While the end result is the same, I think declaring performance irrelevant is misleading. I originally interpreted this thread as saying something like: "Rate monotonic scheduling cannot guarantee atomicity in todays SMP world, therefore we must do something else for atomicity. (For example Pavel's ringbuffer code.)" "Having solved atomicity some other way, rate-monotonic scheduling is no longer needed, so we can drop it in posix." I have no issue with the first sentence. However the last sentence is wrong. In the original design, rate-monotonic scheduling was done for performance reasons. It's atomicity benefits (on single core systems) were strictly a side effect. Rate-monotonic scheduling is STILL NEEDED for performance reasons. It is not something that can simply be declared irrelevant. And every variant (posix, RTAI, RT_PREEMPT, Xeno, etc) should provide rate- monotonic scheduling. Atomicity has nothing to do with it. I realise that I brought up atomicity myself with my first post about communication between the parts of stepgen. At that time I wasn't clear about what the goal of the discussion was. > The answer is directly relevant for this: can non-conventional > thread setups like coprocessors not coordinated by the OS > (ala PRU, DSP etc) be used in the future or not. This is the core of the discussion. Rate-monotonicity is irrelevant. It cannot guarantee atomicity when RT code is running on more than one core, or when the "base thread" is running on a PRU or FPGA. So lets agree to stop talking about scheduling and start talking about how to achieve atomic transfers with these new architectures. > encoder.c and stepgen.c should be made to perform correctly > in face of arbitrary thread priorities and thread preemption. Yes, of course. > I think this is relatively little effort in terms of code. The result > must certainly reviewed thoroughly under the new baseline > assumptions, but it is not rocket science either. **) The existing code must first be reviewed thoroughly under the new baseline. As mentioned earlier, a side effect of rate-monotonic scheduling was that it became a little easier to do the atomic stuff needed in stepgen. So now, we need to make sure the code no longer relies on un-preemptability. We may find that little or nothing needs to be done. I started to review stepgen for a reply to this thread, but my employer would rather I spend my working hours on work. (They are funny that way.) I saw enough in that quick look to tell that would be educational to review the code on-list. I believe only tiny tweaks will be needed for stepgen. Certainly nothing like adding ringbuffers. I have a busy evening tonight, and work tomorrow, but I hope to post the analysis of stepgen.c tomorrow evening. > Do we have any other candidate components which are > affected by such revised assumptions? I'm not aware of > any right away. Stepgen, pwmgen, and encoder are the ones I can think of right now. -- 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