The solution we are talking about here has been taught in introductory computer science classes going back at least to the early 1970s. I've seen this used in the operating system on 60s vintage mainframes.
But what is different in each case is the method used to ensure mutual exclusion. Some processors have CPU instructions for this and others don't. Some small machines can't even read a pointer from memory n a single atomic cycle. So textbooks list about a half dozen ways to do this. But we are talking about a system that runs on an RTOS. Every RTOS I've seen provides some kind of queue for interprocess communication so the programmer does not have to worry about details like this. It is really easy to get DIY queueing software wrong so it is best to use the well-debugged API provided by the OS. On Sat, Jul 27, 2019 at 2:37 AM Nicklas Karlsson < nicklas.karlsso...@gmail.com> wrote: > On Fri, 26 Jul 2019 22:06:23 +1000 > Erik Christiansen <dva...@internode.on.net> wrote: > > > On 22.07.19 18:48, Nicklas Karlsson wrote: > > > Algorithm data is filled in a round buffer and sending/saving process > > > should send/save the tail in not to small blocks. One counter for > > > filling and one for sending/saving should do the trick. Atomic > > > increment including overflow should solve the problem but as each > > > counter is updated by one process only I guess atomic read/write is > > > eough if properly done and I expect using an int will be atomic but > > > maybe there could be an ordering problem if CPU reorder instructions? > > > Or? > > > > On and off over 30 years, I wrote multi-threaded telecommunications call > > control software, initially for trunk systems, then for PABX. It was > > embedded real-time, run for years without a reboot, and no dropped calls > allowed. > > > > What worked for me there, for foolproof interprocess communication was a > > simple circular buffer with a read pointer chasing a write pointer. If > > same, it's empty, else data available. I always wrote the buffer in > > assembler, and simplified circularity-wrapping by making its length a > > binary multiple and wrapping with a bitmask. Message packets were also > > of binary multiple length - often as little as 4 bytes. > > > > Atomicity? I always disabled interrupts during a queue read or write. > > Those assembler functions took around 2.5 uS on a 20 MHz AVR ATmega, and > > half of that is context switching. The remainder included setting and > > clearing the semaphore which tells the consuming process whether there's > > anything in the buffer. > > I sometimes use similar scheme on Micro controller, read pointer chasing a > write pointer. For atomicity I use read modify write of variable from one > process only and assumed read/write of variable is atomic and as I use > interrupts with priority I also know one process may interrupt the other > but not the opposite so I have been able to get by without disabling > interrupt. Reading process will always get either new or old value. > > Sampler, halsampler seems to work great though I get some problem with > overrun though a single missed value sometimes does not matter to much. I > think halsampler use a similar method, read pointer chasing a write > pointer. In case of full FIFO old value are overwritten which works great. > > > Regards Nicklas Karlsson > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
