On 3/3/2014 5:16 PM, John Kasunich wrote: <massive in-line snippage>
> Can we agree that on a single core system, slow threads should never > steal the CPU from fast threads, and web browsers should never steal > the CPU from any "real-time" threads? Even if you are only doing > simulated real-time? Even on a single core system, there are more ways to implement thread scheduling than "you can shake a stick at". The important issue is the code operates correctly under the implemented scheduling scheme. The "right" scheduler is the one that works for your application. That said, I don't have an issue with your proposal, although terms like "fast", "slow", and "real-time" should probably be rephrased in terms of relative thread priorities. > It would be foolish to try to implement a ringbuffer or other fairly > heavy-weight protocol in an FPGA. Instead, you define a register > map by which the slow task controls the fast hardware. Ideally > every register is independent and the FPGA does the right thing > regardless of what order you write them in. > > In some cases, there may be groups of registers that need to be > atomic. It isn't uncommon to have double-buffers with a strobe > or similar signal that tells the FPGA to transfer from the first set > to the second set in parallel. I totally disagree. I work with FPGA systems on a daily basis, and would be completely crippled if you remove ringbuffers (and their identical twins: FIFOs and queues) from my "bag of tricks". These constructs are used extensively in my designs for the exact same reasons we need them in the new real-time layers: Communicating chunks of data atomically across clock domains (or threads / scheduling contexts in software). These constructs are non-blocking, and serve to isolate various timing domains from each other while providing for highly efficient transfers of data/messages/whatever. -- Charles Steinkuehler char...@steinkuehler.net ------------------------------------------------------------------------------ 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
