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. Erik _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
