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
