+1 ! non-blocking datastructures are indispensible ! 2014-03-04 16:15 GMT+01:00 Charles Steinkuehler <char...@steinkuehler.net>: > 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
------------------------------------------------------------------------------ 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
