On Mar 28 2015 6:16 PM, Jeff Epler wrote: > On Sun, Mar 29, 2015 at 12:02:43AM +0000, matic bie wrote: >> Hi,friends: >> The source codes showed in the following picture, my puzzling >> question : >> 1) I looked up all the project's codes ,but i did not find anywhere >> the "emcmotCommand->head" and "emcmotCommand->tail"changes. Can >> anyone know ?2)"emcmotDebug->split++", here what's the meaning of >> the >> word "split",and what does it represent? >> >> > > ->head and ->tail are a very simple synchronization method between > task > (userspace) and motion (realtime). > > Here's how it's supposed to work: task and motion have a shared > memory > area which contains an emcmot_command_t structure. task writes a > command to it, and motion reads out the command and acts on it. > > The structure's first field is "head" and its last field is "tail". > emcmot_command_t is too large an object to be copied atomically, so > there is the possibility that motion sees a partially-updated version > of > the structure. > > motion is supposed to: > * increment "head" > * set all the other felds in the emcmot_command_t > * increment "tail"
It has been a LONG time since I had to deal with stuff like this, but it sounds like the code might not be implementing the locking/mutual-exclusion properly. You might want to look into the following: http://en.wikipedia.org/wiki/Consensus_%28computer_science%29 http://en.wikipedia.org/wiki/Test-and-set http://en.wikipedia.org/wiki/Raft_%28computer_science%29 > if it does this, then task is supposed to be able to: > * make a complete copy of the emcmot_command_t > * compare head and tail > * if they are equal, it has a consistent copy > and it can act on the contained command > * if they are unequal, then it is an inconsistent > copy and it will try again after a short time (typically 1 > servo period or 1ms) -- this is a "split read" > > However, I agree that searching the source code does not find the > place > where emcmotCommand->head or ->tail are incremented. > > The same scheme is used for other structured data passed between task > and motion. Some of these do have head++ operations, e.g.,: > emc/motion/command.c: emcmotStatus->head++; > > Additionally, this scheme was designed for simple CPUs of the 90s, > and > it would not hurt to reevaluate whether the scheme still works on > today's SMP machines with their memory ordering promises ('char' is > not > typically a good type for memory operations that are desired to be > "atomic" on non-x86 systems either); and whether there are now > better-recognized synchronization primitives that could be used > instead. > > As far as I know, emcmotDebug->split is supposed to be a monitor of > the > number of times a split read actually occurs. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
