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"
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.
Jeff
------------------------------------------------------------------------------
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
