On 01/11/2014 05:43 AM, Michael Haberler wrote: > Am 11.01.2014 um 05:19 schrieb andy pugh <[email protected]>: > >> On 11 January 2014 02:59, Charles Steinkuehler <[email protected]> >> wrote: >>> I think I've come up with a reasonable solution >>> that will still work with HAL's limitations (only bit, integer, and >>> float data types, so no strings). >> Wacky idea, why not add strings to HAL? (if you do, then I suggest >> _not_ zero-terminated) >> >> it could be useful for all sorts of config type stuffs > yes it would, but as Charles says: it would break the atomic update > requirement assumed by HAL data types. You cant guarantee a string copy will > not be interrupted; for the basic types you can. This guarantee maxes out at > 8 or 16 byte sized values, depending on architecture, so it's unsafe > territory beyond 8 and architecture dependent. HAL assumes sizeof(double) can > be updated atomically as largest object (8). > > This means strings may travel to/from RT components on a message queue, but > not as pins > > the difference between sending/receiving a message and updating a HAL pin is > that the message creation/interpretation code may be interrupted as long as > the enqueue/dequeue operations are atomic, which they are in Pavel's > ringbuffer code; interruption may not happen for pin updates > > in the ringbuffer variant this is the sequence 'reserve space in queue', and > 'enqueue'; both are atomic - any interruption between the two permitted > > the legacy code does not have an atomic enqueue operation but checks on the > receiving side that enqueue operation is complete (in case you've ever > wondered what the SPLIT_READ stuff is - that is detecting 'enqueue commit' on > a queue which must be size one, so it's really just a shared buffer) > > -- > > if you are just dying to transport a short string of max size 8, you can > recycle a HAL_FLOAT, interpret as char[8] and it would be atomically > updateable _by storing/reading a double (not using memcpy() etc!), but it's > royal wart and it stinks. > > The solution to this will be making messaging interactions between components > trivial, then the issue goes away. Right now it's jumping the hoops. > > - Michael > > > As an admitted neophyte to this space, you can tell me to go to my corner and be quiet, but I can't help asking why configuration data, which is what the pin info is all about - startup setup information that can get stored locally in the driver once received - why this needs to be atomic. I can certainly understand 'operating' parameters requiring an atomic characteristic, but I'm trying to see the reason in this case.
Seriously, I do NOT want to steal bandwidth from this important work so 'quiet' will be taken respectfully. ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
