Am 04.03.2014 um 23:07 schrieb John Kasunich <jmkasun...@fastmail.fm>:
> > > 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. > ... > Rate-monotonic scheduling is STILL NEEDED for performance reasons. let me bubble up and clarify my footnotes to CONTAIN the excitement ;) *) note this has only to do with preemption of higher-priority tasks; it has nothing to do with relative scheduling rates **) this does not suggest to give up on thread priorities; it suggests not to rely on priorities for correctness. **) means: in the future, one may NOT rely on thread priorities to ascertain --> correct behavior <---. It explicitly says that for the current scheduling scheme no change is required. So I dont understand what you are trying to defend. The whole point is: components should be bulletproofed so you can drive your scheduler by a random number generator for thread priorites and the result is still correct. That does not say the performance will be better. However, some current components will positively keel over if you do that. So that criterium includes that under the proposed change to _components_ you can run any scheduling regime, including the current one. Not sure how I should make that point any more clear. > 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. I am really looking forward to that. These are critical components. Ah, pwmgen too. Thank you in advance! - Michael > >> 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 ------------------------------------------------------------------------------ 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
