Re: [linux-audio-dev] lock-free ring buffer code

On Fri, Apr 04, 2003 at 05:03:54PM +0200, torbenh(a)gmx.de wrote: you should design your system so that it never happens. (based on the fact that most well behaved rt tasks are somewhat periodic and don't take 100% of the cpu). the way i've done this in my applications is to use the fact that in general, some item is given to the RT thread who later gives it back. this pattern pops up alot because the RT thread shouldn't malloc or free memory, so anything non-static generally comes from somewhere outside. so before a writer puts something on the queue to the RT thread it first dequeues everything returning from the RT thread, and then enqueues its item. since these items are conserved, the RT thread can never write back more items than it is given, and it may never be given more items than the queue can hold. so as long as your queues are equal length, it's generally all good. this is specific to the tasks i've used it for though. if you want to be woken up a soon as possible, maybe run a lower priority RT thread which will guarantee you cpu time after the higher priority one (which can then do some dirty work, possibly with locks or file descriptors). (alternately find a better operating system that supports application level scheduling (exo-kernel), scheduler activations, closures, whatever). i think though, that the waking-up issue is separate from the lock-free-messaging issue and should be solved separately according to the problem at hand. conflating the two will only end in bloodshed or at the very least an upset tummy. rob ---- Robert Melby Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a Internet: async(a)cc.gatech.edu