There is a LOT more to this. 1. Dual or multi-core CPUs add some complexity because all the CPUs share a common memory. What if all four CPUs try to run the "test and set" at the same time? Also, you can no longer assume an interrupt handler has exclusive use of memory. 2. what if the process uses two queues? Process A might hold access to Queue X and process B holds Y and then each waits for the other process to release the other queue and the system deadlocks. 3. what if there are more than two processes? How to ensure that access to the queue is fairly sharded between four or six users? 4. What if the CPU you are using lacks a test and set instruction?
There are good solutions but today NO ONE has to solve these problems solutions were worked out 50 years ago. On Sat, Jul 27, 2019 at 10:22 AM John Dammeyer <jo...@autoartisans.com> wrote: > So true. Most RTOSs have both Semaphore and Mutex features. > > Even a simple Test and Set instruction where if the location is set the > resource isn't available are easy to use. For the non-comp sci people the > Test and Set looks at the location and sets or clears the Zero flag before > setting the location to 1. If the location was already 1 then the zero > flag is set to FALSE. If the location was 0 it will be set to 1 with the > zero flag set TRUE. The next step of the program then tests the zero flag > to determine if it now has exclusive use of the resource or if some other > task/thread was already using it. > The test and set cannot be interrupted and the location cannot be modified > by DMA (direct memory access) from another hardware device. > I don't know if the ATMEL device used in the original Arduino has that > capability. But the bigger processors all pretty well do. > > John > > > > -----Original Message----- > > From: Chris Albertson [mailto:albertson.ch...@gmail.com] > > Sent: July-27-19 8:58 AM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] Real time data write to file, unexpected real > time > > delay --> sampler, halsampler > > > > 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 > > > > _______________________________________________ > 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
