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): - is there *any other use case* for the current priority/non-preemption scheme than (2) above, which is: preventing interleaved shared state access by making the thread a de-facto critical region? 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. I think the answer is 'no'. If we can agree on this, I suggest to proceed as follows: encoder.c and stepgen.c should be made to perform correctly in face of arbitrary thread priorities and thread preemption. 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. **) Do we have any other candidate components which are affected by such revised assumptions? I'm not aware of any right away. - Michael *) 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. ------------------------------------------------------------------------------ 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
